today I helped update a machine where the following update issue was at hand:
viber has added a libjpeg6 dependency. Now, there is no package libjpeg6, but there are several packages providing it. pamac-gtk wasn’t able to run this update reporting “libjpeg6 not found”.
However, I just tried installing viber using pamac-gtk on my machine and it correctly showed me a menu asking to choose between several available packages providing libjpeg6. So the issue only appears when updating.
Unfortunately, I cannot tell how pamac-cli or AUR helpers like yay would have handled the issue because I just installed one of the possible packages by hand to work around it.
Is this a little bug in pamac(-gtk) which I should report? Or maybe something that the viber packager messed up? Or something messed up on the problematic machine?
Just want to get my software updated by package management. Don’t know whether this works with a Viber AppImage. I use an AppImage for an app where there is no alternative, and there I need to download a new version every now and then, while (AUR) packages are handled by yay/pamac and offer updates comfortably and without me having to think about them.
When installing, even pamac-gtk does so. But when updating?
Well, but libjpeg6-turbo and libjpeg6-turbo-bin both provide libjpeg6 so I’d expect the package manager to pick it up and propose all candidates instead of failing… It does work when installing, just fails when updating for some reason…
Otherwise, as you know, aur is not officially supported and if something is wrong with an aur the right place to report is to the aur developer.
Thirdly, pamac functions the same way regardless if installing or updating. In the case of an aur, there in no update, it is rebuilding. A thing to consider is the build recipe may be outdated or changed (so you might want to clean the cache and rebuild). And in case of large complicated software like viber it will need many aur dependencies. If the packager of any one of them did not update his recipe the whole thing will collapse.
Generally, for bulky proprietary software, me personally prefer the flatpak or appimages if they are official, or whatever is on their website, or aur only if it is just unzipping the official debian package. This way one has least headaches on update.
And lastly, in the above example building with pamac, the first choice of git is the most problematic. I would choose 4.
If a dependency appear to be resolved by an existing package, the package manager will not provide the option to select another package providing the dependency.
I think this is by design as pacman will work the same way.
The following is speculation
In this case - now I am guessing - it could be that, when viber was originally added to the system, assuming it also at that point required the dependency - a package providing libjpeg6 was added to the system.
Even if a package with the name no longer exist - with that name - the requirement, the dependency is seen as met - but possibly needing a version bump - and thus the option to select the provider is not shown, but as the package no longer exist the update fails.
As it is an AUR script - it is quite likely that one has to resolve such inconsistency manually.
I think I recall that Pamac - at least to some point - couldn’t resolve all non repo dependencies automagically.
What would be the correct name in this case? There are several packages that provide libjpeg6, so it is actually a good thing to not hard code it to a specific package but let the user choose. Maybe some users want to use libjpeg6-turbo and some want to use libjpeg6-turbo-bin to save compile time.
This works nicely when freshly installing viber, but fails when updating it. In my opinion this is actually not the packager’s fault.
I see, thanks for the hint! My practical problem is solved anyway by installing the dependency manually, I just wanted to discuss pamac’s behavior and possibly help troubleshoot a little bug there.
That’s a too broad-brush statement. Some issues originate from the AUR package, others from the AUR helper. In this case I suspect the latter to be the case.
It should, at least!
I don’t quite see the difference between AUR and repo. In both cases, a new package is installed (for AUR it’s first build, then installed) potentially overwriting the old package’s files. If there was no old package, we call it installing, if there already was an old package, we call it updating.
That’s a good hint, though I’d expect pamac to take care of it automatically before building an AUR package.
Well, we know exactly which dependency is problematic, no need for such generic warnings!
This makes sense, but no package explicitly named libjpeg6 exists, only several packages providing it.
Unfortunately, no, libjpeg6 has been newly added in the problematic update, see changelog: Making sure you're not a bot!
$ pamac install viber
Warning: viber is only available from AUR
Preparing...
Checking viber dependencies...
Resolving dependencies...
Checking inter-conflicts...
To install (2):
numactl 2.0.19-1 (Required By: viber) extra 84.8 kB
libxml2-legacy 2.13.9-2 (Required By: viber) extra 615.2 kB
To build (1):
viber 27.0.0.1-3 AUR
Manjaro Wiki - Using the pamac CLI - Cleaning the Cache
When pamac installs packages, it keeps a copy of all the old packages you have downloaded. This cache can be very useful if you have to install older packages in an emergency. However, left unchecked, this cache will grow very large over time.
Otherwise, to clear the cache completely, enter the following command (and use with care):
pamac clean
Cache can also be cleaned in pamac GUI preferences:
As a side note: the build cache is not cleaned automatically when new version of the aur package arrives. In some cases it can save significant amount of time and this usually works if there was only a minor update. Only if the new build does not work one should do a “clean build” as yay calls it, a.k.a. delete the cache.
I use yay as aur builder so i cannot say if pamac is buggy in that area. If it does not as for “provider” it would seem like a but to me.