[UX][enhancement] check for self-updates (including auracle) before updating other packages

[TheBeardOfTruth]

Version

Applies to all versions as it's a design choice, not a bug.

Description

Every time auracle and/or pacaur updates pacaur will break, requiring a manual rebuild.

This is, honestly, pretty clunky and could be solved by doing a quick self-update check before installing anything.

Output

pacaur -Syu

:: Starting AUR upgrade...
auracle: error while loading shared libraries: libalpm.so.12: cannot open shared object file: No such file or directory
:: adwaita-qt is not present in AUR -- skipping
:: alchemy is not present in AUR -- skipping
:: ant-gtk-theme is not present in AUR -- skipping
:: archlinux-artwork is not present in AUR -- skipping
/* output truncated */

[AladW]

It's only on auracle updates. Old pacaur circumvented this by only using cower (now auracle) for searches. I guess this was refactored here, so you have the issue every AUR libalpm backend has since package-query: break completely on libalpm bumps.

[TheBeardOfTruth]

True, but the UX enhancement here is to make pacaur aware of this via either:

1) checking for an auracle update before checking for any other updates (though checking for pacaur updates should pull auracle updates as well since they form a dependency chain) 2) detecting an auracle and/or libpalm update and then updating auracle first 3) detecting an auracle and/or libpalm update and deverring those updates until last

Or any other scheme that prevents pacaur's aur search from breaking on system update.

[FatBoyXPC]

So I need to re-build/reinstall auracle-git the manual way (as if I didn't have an AUR package manager) to get past this auracle: error while loading shared libraries: libalpm.so.12: cannot open shared object file: No such file or directory?

Edit: Yes this worked. Cool. I do agree - this requested enhancement sure would be nice!

[AladW]

Or any other scheme that prevents pacaur's aur search from breaking on system update.

Well, when there's an auracle update there's not necessarily a libalpm update, or vice-versa. As far as I know, pacaur also doesn't depend on a specific version of auracle - the auracle command-line interface doesn't change often.

So you'd have to check explicitly on a missing soname. But then, rebuilding auracle might not even work because of API changes in libalpm.

In other words, besides a warning to the user or not depending on auracle in the first place, I don't think there's a robust way.

[TheBeardOfTruth]

Robust is subjective, innit? We know that auracle depends on libpalm, so if either's flagged as needing an update (almost certainly only libpalm, a new auracle update shouldn't break so long libpalm doesn't change) we should update auracle first, which ought to pull libpalm as a dependency.

Sure, this isn't robust in the sense that it might stop working correctly if auracle's updates change, or if libpalm's package name changes, but that would be true for any self-update check and is significantly more robust than just not working anymore after updating.

I like to think of it as "degrees of robustness", absolutely robust would be to not have any dependencies, that way it ought to always work irrespective of updates. That's also unreasonable and impractical, the next best thing is to try to leverage the dependencies in a manner that avoids problems, true?

Auracle, to my understanding, is used to search the AUR and to download packages from it. At least if the readme.md is to be trusted. We can therefore infer that likely pacaur invokes auracle with the right arguments to update packages. This would then search the AUR for updates, and clone all of them.

After this it would then, presumably, hand each package off to makepkg, so it ought to be possible to either do the auracle search first, then update repo packages, and then makepkg the cloned repos from earlier.

Or to use auracle to clone itself when libpalm updates are present, though this feels like the less robust solution of the two.

Honestly the first two of these sounds the simplest, if the source code is well structured it should only take a couple lines of source code to fix, if I have the time later this week I'll see if I can't put together a pull request.

[AladW]

On 22/06/2021 19:16, Andreas Björkman wrote:

Robust is subjective, innit? We know that auracle depends on libpalm, so if either's flagged as needing an update (almost certainly only libpalm, a new auracle update shouldn't break so long libpalm doesn't change) we should update auracle first, which ought to pull libpalm as a dependency.

libalpm is part of pacman, and will be updated as a part of it. People will almost certainly have updated pacman before they updated (or rebuilt) their aur helper.

Sure, this isn't robust in the sense that it might stop working correctly if auracle's updates change, or if libpalm's package name changes, but that would be true for any self-update check and is significantly more robust than just not working anymore after updating.

I like to think of it as "degrees of robustness", absolutely robust would be to not have any dependencies, that way it ought to always work irrespective of updates. That's also unreasonable and impractical, the next best thing is to try to leverage the dependencies in a manner that avoids problems, true?

Auracle, to my understanding, is used to search the AUR and to download packages from it. At least if the readme.md is to be trusted. We can therefore infer that likely pacaur invokes auracle with the right arguments to update packages. This would then search the AUR for updates, and clone all of them.

1. The only distinguishing feature of auracle is auracle buildorder. The ironic part is that pacaur still uses its own (slow) solver. Maybe that's not a bad thing considering the sheer amount of AUR requests buildorder uses.

2. Downloading packages can be done with a simple git command. Merging changes can equally be done with git directly.

3. Searching, in particular formatted output, is more annoying, but retrieving package information (i.e. for updates) can be done directly as well.

In other words, the simplest approach is to isolate auracle for its formatted search ability and disregard it for anything else. This is similar to what older pacaur revisions did. So it's not really unreasonable.

After this it would then, presumably, hand each package off to makepkg, so it ought to be possible to either do the auracle search first, then update repo packages, and then makepkg the cloned repos from earlier.

Or to use auracle to clone itself when libpalm updates are present, though this feels like the less robust solution of the two.

auracle can't do anything on a libalpm update without rebuilding it. With a broken dependency, it doesn't run. That's why I think using it only for specific tasks is the best approach.

Honestly the first two of these sounds the simplest, if the source code is well structured it should only take a couple lines of source code to fix, if I have the time later this week I'll see if I can't put together a pull request.

P.S. It's libalpm, whenever I hear libpalm I have to think on my old Palm device.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/E5ten/pacaur/issues/30#issuecomment-866176983, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKASJDFV6NM5GFNB4EKY6LTUDAO3ANCNFSM46TYJDGQ.

[E5ten]

I agree with @AladW that there isn't a robust way to handle this. In regards to buildorder, I thought that it doesn't handle versioned deps correctly? If it does/there's a way to get around that and still make use of its faster solver, please let me know. I'll consider reducing what auracle is used for, but given that this issue is specifically in regards to treating it specially on libalpm updates, I'm closing it.

[AladW]

On 22/06/2021 20:55, E5ten wrote:

I agree with @AladW https://github.com/AladW that there isn't a robust way to handle this. In regards to buildorder, I thought that it doesn't handle versioned deps correctly? If it does/there's a way to get around that and still make use of its faster solver, please let me know. I'll consider reducing what auracle is used for, but given that this issue is specifically in regards to treating it specially on libalpm updates, I'm closing it.

Ah right - I forgot about the versioned dependency part. Then again, it seems the pacaur solver has more noticeable issues than incomplete support for versioned dependencies, i.e. #13.

In any case, you could do a manual verification of the dependency chain after retrieving it with auracle. I did this in a few lines of awk (https://github.com/AladW/aurutils/blob/master/lib/aur-graph) but it's not 100% accurate.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/E5ten/pacaur/issues/30#issuecomment-866248275, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKASJBUH4HEOQXO6LTR6DTTUDMB5ANCNFSM46TYJDGQ.