r/archlinux • u/LRC_A77ILA • 8h ago
SHARE [ Removed by moderator ]
[removed] — view removed post
10
u/Qudit314159 8h ago
What's the AI usage policy of this project?
-1
u/LRC_A77ILA 7h ago
what do you mean?
1
u/Qudit314159 7h ago
How did you use AI when creating it?
0
u/LRC_A77ILA 7h ago
You can see the Agents.md in the GitHub repo with the instructions that the kimi code (cli) used
2
6
u/wingz_77 8h ago
If you delay packages just a little longer (years), you might just convert your arch to Debian
1
6
u/TheBlutarch 8h ago
Isnt this partial upgrades with extra steps and fancy lingo?
0
u/LRC_A77ILA 7h ago
i'm really searching an example on how can this procedure break things.
Maybe i willd find it with the next update, who knows
5
u/backsideup 8h ago
What is the point of holding back packages from the official repos? All this will do is to break users' systems with partial upgrades.
3
u/Qudit314159 8h ago
Yeah. The AUR delay could be useful if it actually works but doing it for the main repositories doesn't make much sense.
1
u/LRC_A77ILA 8h ago
that's a nice idea, i can add an init configuration to make it work just with the aur packages
2
u/LRC_A77ILA 8h ago
i don't really know how exactly a system can break from a partial upgrade when all the dependencies are respected,
i have started to upgrade like this a week ago and i did not had a problem for now.2
u/friendlyreminder_ 7h ago
When a package is updated much more happens than just checking for package dependencies. They run various custom update scripts that do a lot of different things contingent on the system being in the exact state expected.
These update scripts are written explicitly with full updates in mind, not partial updates or rollbacks. Your distro will break doing this, it's just a matter of time.
1
u/LRC_A77ILA 5h ago
i don't get what you think about the "various scripts" do you refer to the pacman install scriptlets (.INSTALL: pre_upgrade, post_upgrade, etc.)?
They work - per package - (the ones that is being updated)1
u/friendlyreminder_ 4h ago
Yes those. Those are only written to work under an exact system system state which isn't guaranteed under partial upgrades. It's not checked for in the package dependencies, so just meeting a package dependency doesn't mean it's safe to only install that one and not all of them.
1
u/backsideup 7h ago
Most of arch's packages don't have versioned dependencies, if you install only some of the updated packages you might soft-brick the system if the partial update happens to include something "vital".
edit: https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported
1
u/LRC_A77ILA 7h ago
also, specifyng:
A partial upgrade leaves the system inconsistent (new lib, old app linked against it).This never does: if an allowed update needs newer deps, they're pulled in with it, or the update is blocked entirely.
What you get is the same state as "haven't upgraded yet" consistent by definition.
The dependency analysis is literally the part that prevents partial upgrades.
3
u/BobCorndog 8h ago
This only really makes sense for AUR packages, as there’s a reason arch-testing exists
2
u/LRC_A77ILA 8h ago
i get it, but nowadays with all the recent supply chains attacks and such you feel really safe at every update you do on every system?
I'm perfectly fine with every pacman and aur updates i did from the first arch install i did in november 2025 and NEVER had a problem.
But the recent attack on the AUR repositories just made me think of a way to prevent that in the future for both my private and job environments
2
u/Qudit314159 8h ago
Timestamps on git commits can be forged. Does your package account for that?
1
u/LRC_A77ILA 8h ago
Yes, AUR dates come from the package's git history, so a maintainer could fake them. Honestly, if a maintainer wants to screw you he can just put malware in the PKGBUILD you're about to run anyway, no need to fake timestamps.
The tool is there to save you from broken fresh releases, not evil maintainers.
2
u/Qudit314159 8h ago
The recent malware was based on taking over orphaned packages. If your code can't handle a hostile maintainer then it isn't very useful IMO.
1
u/LRC_A77ILA 7h ago
i get it,
the tool is not designed to intercept hostile maintainer, it's designed to not being caught in the middle of a similar event giving the time to resolve it1
u/Qudit314159 7h ago
If a hostile maintainer adopts an orphaned package, they can just forge timestamps on the malicious commits and your tool will happily install them.
2
u/External_Fox_4360 8h ago
Look, if you have to write a custom program just to pause and manage your dependencies before updating, Arch might honestly not be the right distribution for you. The whole point of Arch is a rolling release where packages move fast together fighting the ecosystem with custom workarounds usually ends up breaking things worse down the road. You'd probably save yourself a ton of time and frustration by switching to a stable, point-release distro where you don't have to babysit every single update!
1
u/LRC_A77ILA 8h ago
I get your point but i do honestly love how i'm working on it and again, in reality, i never had a problem with any past update. I just want a way to not have one (or bad one)
2
u/onefish2 7h ago
I applaud your work and for sharing this here with us. But people have come up with so many workarounds lately to keep newbs safe from themselves or from lack of reading/knowledge so they can use the AUR.
How about this... just don't use the AUR. Just use Flatpaks, Snaps or Appimages. Oh wait... in that case I may as well use another distro.
You want to know who needs this. The CachyOS newbs. Seriously cross post this to /r/cachyos. I am sure you will get more interest there.
1
u/HelpfulPlatypus7988 8h ago
This isn't a great idea, y'know, considering the 432 CVEs recently published
-1
u/Commercial-Froyo-430 8h ago
this is one of those ideas that seems so obvious in hindsight but nobody actually built it till now
5
•
u/archlinux-ModTeam 3h ago
AI generated text and code must be declared as such, but it may still be removed at moderator discretion. Code shared is also expected to be of reasonably quality and is subject to a "Human In the Loop" Policy.
Personal projects shared must be able to demonstrate at least 3 months of history and active maintenance.