Feature request: A better handling of packages being dropped to AUR


Hello, Community!

Recently, ffmpeg2.8 has been dropped to AUR, probably because it conflicted with the new x265 version. The update introducing this lead to a message telling the user about the conflict. For an experienced user this is enough information to do a quick research, figure out that ffmpeg2.8 has been dropped to AUR, remove (or rebuild?) it.

For an unexperienced user, however, this is a problem which is hard to handle. By “inexperienced user” I mean people like my >60 years old father who otherwise is able to use Manjaro and keep it updated but is absolutely confused by a situation like the package conflict described above.

Also note that the problem arises not due to the discouraged AUR usage but also hits the well-behaved users who haven’t the AUR enabled.

I would propose the following handling of such an issue:

  1. Check if an update leads to a conflict.
  2. Check if this is due to a package which is installed but not available through the repos (that is, only available from the AUR).
  3. Check if the conflicting AUR package has been installed explicitly by the user.
  4. Check if the conflicting AUR package can be safely removed without removing any other package which has been explicitly installed by the user.
  5. If all checks are positive, propose the conflicting package for removal (I assume that this would apply to a large percentage of users). If check 4 is negative, show some horrifying message listing the packages which were explicitly installed by the user and would be removed together with the conflicting package. If the user chooses to keep the conflicting package: If a rebuild would solve the problem, offer the rebuild.

In short: Give the user more information on the conflict in place and propose different ways of handling it.

Are there some obstacles with such a mechanism? How hard would it be to implement it? I think, reducing package conflicts during updates would be a great step towards making Manjaro even more beginner-friendly than it already is.


IMHO, there isn’t much purpose to three branches if this kinda stuff can’t be handled upstream in either Manjaro Unstable or Testing, prior to it hitting Stable for reasons exactly like the difficult upgrade question your father faced. This type problem is not exclusive to Manjaro, either.

And arguing that “it’s leading-edge and to be expected,” indicates to me enough forethought wasn’t put into the reasoning behind three separate branches if little stuff like this can’t be handled. What is little to some may be mountainous to others.

That said, some things just fall through the cracks sometimes. It’s to be expected. Perhaps you should examine the role you play behind a Manjaro installation on your father’s computer.

Whatever the solution, I hope you find a working one.



Well, obviously, I am in charge whenever something breaks or an update problem like this happens. But I assume that there is some user group of Manjaro who doesn’t have the luxury of a son taking care of such problems. :slight_smile: Also, it would be easier for me if updates would always go through without my intervention. This actually happens most of the time, there are rather rare occasions (maybe once half a year?) where I need to handle things myself, but I think, it would be the right direction for Manjaro to reduce such occasions even further.


Exactly! And maybe through a preponderance of request posts such as yours the requirement for user interaction can be further minimized. I don’t think either of us is naive enough to believe that it will ever be removed totally, but there it is.

But I don’t remember if you were here in the “Olden Days” of Manjaro (I think you were?), 'lo these many months ago, but I do remember when we only had a few updates per year and none–absolutely none of those ever came up smelling like roses, We’re ever so fortunate for @philm & Co.'s work since those days. :smiley:


Actually, I use Manjaro since 0.8.10 or something like that. :slight_smile: Don’t remember how updates were back then but I definitely agree that for a rolling release Manjaro is doing an awesome job, that’s why I even considered installing it on my parents’ machines.


The easiest solution would be to disable automatic updates for AUR packages.
The user should update and upgrade them one by one.


Wasn’t the situation with ffmpeg2.8 such that x265 (a package from extra/) has been updated and at the same time ffmpeg2.8 which still relied on the older x265 version has been removed from the official repos? So it wasn’t ffmpeg2.8 which was updated but x265?

Similar stories happened when gstreamer0.10 or some old webkitgtk version were removed - those packages which were now in the AUR should just be removed to resolve the conflict.


The general idea to handle dependency conflicts during an update it to remove conflicting packages until you can perform the update.
AUR packages like ffmpeg-libfdk_aac use to block my updates quite often. Then I have to remove them and build them later.

Is it possible to make this process of removal of packages less demanding, more automatic? Make pacman assume “Yes” that a user wants to remove a package? The risk is that this automatism could remove xorg, but this is unlikely to happen.


But when the user does not know it’s an AUR package, and thus thinks it’s a required package, because it was installed by default. It gets confusing.


That’s the “plan B” in case that the package which has been dropped to AUR is still necessary:

But if the package which has been dropped to AUR is not necessary any more (that is, has not been installed explicitly and is not a dependency of any explicitly installed package), why not remove it to prevent further conflicts and rebuilds?

That’s a good point, actually. So the danger is that a package which has been not installed explicitly and is not a dependency of an explicitly installed package still can be necessary… But can it happen with a package which has been dropped to AUR (which is the second check from the initial post’s list)?


A script which can be made an option in PacUI or a button in Pamac: “Resolve conflicts”.

I just remember that aptitude never worked for me in resolving conflicts it always ultimately suggested to remove xorg. :wink:


“Resolve conflicts” sounds like some magic which can resolve conflicts universally (could lead to wrong hopes on the part of the users … and then remove xorg :smiley: ) while the algorithm in question is only intended to work for a very particular kind of conflicts, which however seems to be the most frequent case of update conflicts to me. Really, I cannot remember any other update problems besides of official packages being dropped to the AUR (ffmpeg2.8, gstreamer0.10, webkitgtk, maybe further which don’t come to mind) throughout the last few years.


if not explicitly installed (now) AUR packages are no longer required by other packages (which will eventually happen), they get removed automatically whenever you remove orphaned packages.

the only disadvantage of such AUR-fied packages is the update time, which is considerable longer. also, those packages are no longer maintained and could be a security hazard.

there is already a similar check in pacui:

"comm -23 <(pacman -Qqm | sort) <(curl https://aur.archlinux.org/packages.gz | gzip -cd | sort)"
This command compares 2 lists: The first list contains packages, which were not installed from your system repository. The second list contains all AUR package names. By comparing these 2 lists, it is possible to find EOL packages, which will never receive any updates.
These EOL packages were either installed manually by the user or from the AUR (and have been removed from there in the meantime).
Unless you know exactly what you are doing, it is recommended to remove these EOL packages.

thanks for your idea.
i will integrate it in pacui (the “maintain system” option) when i have some spare time.

p.s.: i have added it here.


I’m not sure if pacman and/or yaourt do it, but yay -Syu lists missing AUR packages and local packages not in a repo.

:: Searching AUR for updates...
 -> Missing AUR Packages:  lib32-openssl-1.0-compat  openssl-1.0-compat  openvpn-update-resolv-conf

I think this is useful information to have, but obviously it doesn’t solve the problem. Just a visual reminder when you launch the update process.


Nice, thanks! Do you think, it makes sense to execute this automatically on each update? Because this is actually, what I had in mind. :slight_smile: Or is the idea to give it some testing and then decide?


the part i have implemented only checks, whether not explicitly installed AUR packages are present on a user’s system.
you also wanted to check for packages, which depend on these AUR packages. i have not implemented this. you can check a (e.g. not explicitly installed AUR) package with

pactree -r <package_name>

you can definitely run my code after every update. i have put it in pacui’s “maintain system” option, because i want to separate updates from system maintenance stuff. but this depends on your personal preference.


I remember (Open)SuSE having such a conflict resolving package manager that offered different solutions to resolving conflicts. It was quite decent, but unfortunately also quite necessary.

That is: it would be best to not cause conflicts in the first place. As depreciation is not something that is in Manjaro’s control, a pacui “module” termed “conflict wizard” checking what @Photon has suggested sounds like a sane path forward.


Sorry for the late reply, I was a bit busy lately.

@excalibur1234: I see. Well, PacUI looks really nice but, unfortunately, cannot be used by my father because it is running in a (scary) terminal and is in English. :slight_smile: It would be great if the feature could land in Pamac at some point…