More specifically: I’m proposing that garuda-update should automatically add all AUR (more precisely, foreign) packages to the “ignore list” through pacman’s --ignore parameter.
Why?
There is a common cat and mouse problem when updating older versions of Garuda Linux:
User tries to run garuda-update to update the system.
Pacman sees that xyz-bin relies on libabc=3.141
Pacman rejects the update because libabc was updated to version 5.0
In such cases, the user has to rebuild the AUR package to work with Version 5.0. The Problem is that the user will not be able to rebuild xyz-bin, since they are unable to update the system to have libabc 5.0 in the first place due to the previous conflict.
The corrected workflow
The user updates using garuda-update -a
Pacman ignores xyz-bin and all related dependency resolution
Pacman updates libabc to Version 5.0
garuda-update runs paru to rebuild the AUR packages (including xyz-bin) against version 5.0
This will not affect chaotic-aur or other packages in sync repos. Only foreign packages are affected by this.
I like the idea, perhaps on the wiki there is a different -a that a power user could use something they have to do themselves but is in the wiki or un # from the garuda-update config?
VERY NICE. This would of avoided the headaches from two of the last four big updates. Including the recent one those on Endeavour are claiming for the most part has no issues.
Have the update run twice. still have to enter garuda-update, but when it runs it runs with -a then it rungr without the -a.
Decided to revert the change since it also blocks any kind of replaces=() logic, which is not ideal. Will need to think of a different way to handle this.
What would be nice is to get a heads up about there types of updates and a list of suggestions on handling them before we allow the update to actually start, cause it’s nothing to open another terminal window, do the suggested intervention procedures, then go back to the main terminal and do the main update. I know good chance this would mess up those of us that use Topgrade, and those that use GUI updaters but the trade off I think would be worth it.
I like the idea of ‘a heads up’. checkupdates already does a dry run, maybe add the dependencies that are affected and other possible issues. This output would let one do some investigation ahead of time. When garuda-update is run, the same logic could be presented in the form of yes/no for specific updates. A sort of update what you can until the rest is sorted out.
Should we also consider the case where the package from AUR isn’t a user application, which isn’t a big deal if it breaks, but a core system library? i.e. What if someone is running a custom version of glibc from AUR. Ignoring that during an update could be problematic.
Writing a good heuristic that’s going to catch everything is probably a more difficult task than I first thought.
Ideally, the heuristic would detect which foreign packages are user-facing applications and skip any dependency checks on those, while not skipping any replaces array actions from other packages. Is that reasonably possible without a modified pacman binary? I’m not sure about that.
I think I misread it. I misread it that the user would have to run the command twice. Please disregard what I said ha,
I’d say not? but with out really reading up on it I cant say. But I think a Gauda-pacman pkg spin would be way to hard to maintain long term. It might be better to have that kinda functionality merged upstream? If I am understanding everything right.
Forgive me, but I don’t think I understand the problem that we’re trying to fix here?
I have UPDATE_AUR=1 in my /etc/garuda/garuda-update/config since I want it to auto-update any AUR packages, after it performs all the regular repo updates.
That is the exact reason it blocks it. When an AUR package is built against a specific version of a library, pacman will not let the library update because the AUR package is still tied to the old version. This happens because the AUR updates don’t get applied until afterwards.
Ok, just so I understand, because I’m not that well versed with pacman/ALPM, if you have a package that was installed via the AUR, which lists a specific package/library as a dependency, pacman won’t update the system if there’s an update to that tied package/library that was installed from the AUR?
pacman doesn’t have any knowledge of where a package came from. It doesn’t differentiate between AUR and repo packages. It just sees installed packages. So it sees that you have package A installed that depends on version 1.2 of package B. The repos have an update for package B which would move it to 1.3. Pacman won’t let that happen because it would break a dependency on package A.
When both A & B come from repos, they are updated at the same time and so it works. But when package A comes from AUR, it doesn’t know about the pending update so it blocks it.
