LANG=C pamac search --aur webkit2gtk
...
webkit2gtk-4.1 2.52.3-1 [Installed] extra
Web content engine for GTK
webkit2gtk 2.50.6-7 AUR
Web content engine for GTK
Strangely on other 2 systems I have found webkit2gtk installed (and it takes hours to compile) and I don’t know why it was installed.
Probably removing webkit2gtk and installing webkit2gtk-4.1 will clear the situation
To make the things stranger, the AUR version misses the “required by” and “optional for” fields
$ LANG=C pamac info webkit2gtk-4.1 | rg 'Required|Optional|Depends'
Depends On : at-spi2-core atk bubblewrap cairo enchant expat
Optional Dependencies : geoclue: Geolocation support [Installed]
Required By : networkmanager-openconnect
Optional For : wxwidgets-gtk3
$ LANG=C pamac info webkit2gtk | rg 'Required|Optional|Depends'
Depends On : at-spi2-core atk bubblewrap cairo enchant expat
Optional Dependencies : geoclue [Installed]
Mod edit:Removed zsh-generated junk characters & added line break for clarity.
I like pactree to find depending packages. It will make it easier to find the top level package that requires it.
Just in case it is part of a dependency chain.
pactree -r webkit2gtk
Shows which packages are depending on webkit2gtk (due to the -r option). Adding -o also considers optional dependencies.
It is part of the package pacman-contrib. So you might need to install that.
That’s because webkit2gtk is an AUR package, nothing in the repos requires it. If you had it installed, it would report what package(s) on your system that required it.
Why do you think it is strange? It is to be expected. That is how an orphaned package in the aur occurs at the first place. Something in the repo depended on it, but at some point was automatically migrated to the newer generation thus leaving the old packge as just a spaceeater. And since nothing in the repos depended on the old version/generation anymore, it was also kicked out from the repos.
The repos are the controlled and maintained environment with interconnections and dependencies. If one always uses only repo packages and cleans the orphans regularly, there will never be a blocked update (or at least an easy solution will automatically be offered in the warning).
And that is also why aur is the wild west: full of remnants, abandoned ghosts of the past and many other unmaintained stuff. One can survive there but one has to know how.
Having completed the update Stable 2026-05-02 for all the computers here while holding off processing foreign packages turned on the light bulb full blast. I finally had the context and the reference point for the post by @FiveEyeTea that had started this discussion on whether to do the foreign packages before or after updating. If I had followed my usual procedure of removing those packages before updating I would have run into a similar problem that FiveEyeTea had (and this was similar to the situation back in Stable 2026-03-23 with kdsoap-qt6). Instead, I went with the procedure endorsed by Scotty65 and had no problems at all.
I’m now sold on doing the foreign packages procedure after updating. Thanks @Scotty65!!
It is worth noting, in the pamac terminology foreigns and orphans are 2 different things. In some cases a package can be both.
Orphans are not needed packages. If they are from the repo, they do not hurt. If they are from the aur, they should be removed and before the update at that.
Foreigns are actually flatpaks or AUR. If aur packages are not orphans but instead indeed manually installed and needed, they should be rebuild (one does not “update” them), and only after the repo update, and never at the same transaction with the repo update.
For flatpaks or appimages type of foreigns it does not matter before or after.
No, orphans should be always removed after updating and after removing software from your system. That way, there won’t be any orphans left when you next update the system.
