These numbers is fictive - they are only used for illustrative purpose.
98% of the packages in the Manjaro repo comes from Arch.
0.5% is an AUR package included in Manjaro - usually because it is used by a maintainer.
1.5% is software developed by Manjaro or build from source by Manjaro e.g. kernel and kernel modules, extra modules like Nvidia driver.
If a package is removed from Arch repo - it us usually demoted to AUR - my guess is that users depending on the package have the opportunity to adopt it and maintain it
When such thing happens - the package cease to exist in Manjaro unstable and subsequently stable branch.
Package got dropped from repositories. You’re using or have installed packages (not from the repositories) requiring that package. You have issues because of that.
With the disclaimer that I am not a developer or package maintainer — I am but a lowly, lowly cook moderator — the package that replaces wxgtk2 supports all that wxgtk2 supported.
So it’s only the replacement of one package by a package with another name, and while it may be necessary to remove wxgtk2 first, it is perfectly possible to do this without removing all that depends on wxgtk2. But for that you have to read the man page for pacman.
There’s also an alternative series of events that might affect users who do not have any installed packages / PKGBUILDs that require wxgtk2, yet in the past they might have at one point in time.
wxgtk2 remained installed on their system, not being used by anything, yet still causes a conflict when trying to update the system, such as the Stable Updates from July 18.
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 amulefrom 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.
However, because this is an amule package “update” and not a package “removal”, the unneeded dependency wxgtk2remains 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.
It may have in fact become an “orphan” package, but so are make, patch, autoconf, and automake, which I obviously want to keep. It’s for this reason that I won’t just purge orphan packages if there are no issues.
Of course, the situation with wxgtk2 did eventually become an issue, but there’s no way I could have predicted that many months ago.
I believe that the logic behind “auto-remove unneeded/unshared dependencies” when uninstalling a package should also apply to package updates as well.
After all, one can mimic the above logic by first removing and then installing a package whenever there is an updated version. It would be tedious and redundant, of course.
Here’s how it theoretically would have unfolded in regards to amule:
amule 2.3.3-1 is installed. It pulls in wxgtk2 as a dependency
I notice that amule 2.3.3-2 is available as an update
However, I decide to first uninstallamule, in which wxgtk2 is auto-removed (since it was pulled in as a dependency of amule and no other packages require it)
Now I install amule, which happens to be version 2.3.3-2
I basically “updated” amule, yet wxgtk2 was auto-removed because of my “intermediary” step of first uninstalling amule
I don’t see why the same above process cannot happen streamlined with package updates, and why it’s only triggered by package removals.
These are all part of base-devel group so I don’t see a point having them installed as dependencies. If you ever want to change that just reinstall them: pacman -S base-devel --asexplicit
Probably because Arch is KISS. Also, I guess, you could argue then, why even have any orphans at all, pacman should take care of everything.
The bottom line is: wxgtk2 needs wxgtk-common, which was replaced (+conflicts) by wxwidgets-common. And it (wxgtk-common) couldn’t be removed because other packages (wxgtk2) still needs it.
And you can’t just automatically remove everything that still depends on wxgtk-common (that would be like doing pacman -Rsc).
The bottom bottom line: They wanted to remove wxgtk2. If they wanted to keep it, they could just rename it, same as wxwidgets-gtk3, and change depends from wxgtk-common to wxwidgets-common.
The issue still is that temporary removing wxgtk2 with “pacman -R wxgtk2” doesn’t cure the matter, since wxgtk2 cannot be installed anymore after the Jul 18th update is applied. So your apps that use wxgtk2 and had to be deinstalled, too, are no longer re-installable afterwards. For me these apps are mission critical and thus I cannot apply the update. Would be great if someone knows a work around of some sort.
BTW: In the update there is no such package as `wxwidgets-common listed. So it cannot be excluded, but it seems to come as some other dependency.
It’s removed permanently. Just like an old kernel or python2 or whatever.
Find a flatpak/snap/appimage/container of your apps. Or find an alternative way; there is wxgtk2 in AUR for example, that installs in /opt. Find a way to compile your apps against that.
For example the AUR sooperlooper package does not compile anymore because there is still a dependency on wxgtk2. The maintainer of the aur sooperlooper-git made it compile with wxgtk3. There are a lot of warnings, but it runs.
I understand that it is needed to remove old stuff that conflicts or poses a security threat, but if there is no conflict, and size certainly isn’t an issue also, where is the point here? Just for sake for new, render elder apps unusable?
Snap - thanks, but “no thank you” for any who is security savy.
If your truecrypt containers do not work with a distribution anymore, it is not just a little replaceable something, but a crucial matter - at least for me. The veracrypt approach won’t help, since it is not proven to be free of backdoors and brute password attacks tools exists.
“Any concerns with VeraCrypt are even worse for TrueCrypt (which is abandoned).”
It’s been abandoned for over eight years.
What is with this loyalty to abandoned software which had its own security concerns, of which open-source developers addressed these very issues when they forked it into VeraCrypt?
This turn of the discussion is really what I wanted. Evangilism for a different opinion, but not even a glimpse, no word towards a constructive, and knowledgeable hint that will lead to a solution of the funadmental issue.
In the meantime, I got further with the hint here:
Blockzitat
patryk commented on 2022-07-21 13:22 (UTC). The solution for that package is simple. Please prepare wxgtk2-3.0.5 package based on AUR (en) - wxgtk-3.1.5. Works for me. Version 3.0.5 is still supported.
compiled these and also compiled truecrypt, which failes due to CPP 17++ “byte” data type usage in Crypto.h as described here: Std::byte - Crypto++ Wiki
Also a wrong encoding of the line end character (mix between windows CR+LF) and UNIX CR only in /src/truecrypt-7.1a-source/Crypto/Aes_hw_cpu.asm made things worse. I gave up when the alteration lead to a failure in the CRC check of the bz2 source therefor and I do not have the private key to redo the packaging.
I installed Manjaro in mid 2021. Fresh system.
After some time, 
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 
