Recent stable updates and wxgtk2: what happened?

winnie · 21 July 2022 17:40

UPDATE:

I found the errant package for my situation, which was not an AUR PKGBUILD and not a unique “Manjaro” package: amule

On the computer in which I did a fresh installation of Manjaro in mid 2021, I also installed the package amule, which is from the official Arch Linux repositories.

So even for those who do not use the AUR or custom PKGBUILDs, the Stable Updates from July 18 can still cause this confusing issue. They will not be able to update their system until manually intervening and removing wxgtk2 by hand.

Here is the series of events in my situation, in which no part of the AUR was involved:

I installed Manjaro in mid 2021. Fresh system.
I installed the package amule from the official Arch Linux repository (not from the AUR nor from the Manjaro-specific custom built packages).
At the time, amule required wxgtk2 as a dependency.
This naturally installs wxgtk2 (since it’s a dependency).
After some time, amule (on the official Arch Linux repository) switches the dependency from wxgtk2 to wxgtk3.

Proof: amule 2.3.3-1 → 2.3.3-2 commit changes to Arch Linux package

However, because this is an amule package “update” and not a package “removal”, the unneeded dependency wxgtk2 remains installed on my system.
The Manjaro July 18 2022 Stable Updates are rolled out, and since much time has passed, it’s confusing (and difficult to pinpoint the cause) when the system update is aborted because of the conflict caused by the existence of wxgtk2 and the refusal to automatically remove the errant and obsolete package.

Re-read my above “series of events” and you’ll see that this could have also happened on vanilla Arch Linux, since no part of the AUR was involved, nor was this due to a “custom” Manjaro package.

Nothing needed to be “rebuilt” nor re-installed. If during the update of amule the package wxgtk2 was automatically removed (since it’s no longer needed as a dependency), there would have been no hiccups later on.

I’m aware that you can configure Pamac (and likewise pacman) to automatically remove unneeded/unshared dependencies upon the removal of a parent package; however, I am not aware of any configuration in which this behavior can be applied to parent package updates.