The thing is Pamac is a front-end using libalpm, the same library that use Pacman to handle package management.
So I don’t understand why Pamac would be the culprit here, especially when people could just upgrade without problem usually with Pamac before when there’s nothing systemd related.
If there’s someone that can actually prove in detail that Pamac is doing garbage when upgrading packages, I would like to see that, and I’m pretty sure @guinux would like to fix that too.
If Pamac is considered too problematic, prehaps guinux should stop losing his time to develop and maintain it right now then. It’s kinda useless to develop a package manager in-house if we just end up saying “Use pacman, Pamac is garbage.”
It’s well-known that writing package managers is hard and there are edge- and corner-cases which don’t appear in normal use.
The larger a piece of software gets, the harder it is to keep clean, the more edge-cases.
Just because Pamac uses libalpm doesn’t necessarily mean it does things in the same way as pacman - for example, the update/dependency checking/etc. logic can be very different, and especially so when Pamac also brings in AUR support.
I suspect Pamac needs some TLC, testing, and polish. Just like systemd did with 240.
I’ve been doing pamac upgrades since last October. Nothing ever happened. I have two systems and both always show the same warnings or issues (like the mentioned python cache file). Why? Because most likely I use the exactly same software (packages) on both.
What would be cool (but impossible to do) is to make two databases. One with a list of installed packages of users who’s update though pamac went well and another dB with lists of installed packages of users who had issues upgrading with pamac. A sample of 10-20 users on each dB would be enough. All we would need to do would be to prune out each dB to find the common packages among each user group and finally crosscheck (diff) between the two dB.
I bet a case of beer we would find a very small set of packages that made the difference between the update going through well or not.
I aknowledge that. But it won’t help if we can assure that it does its job correctly to begin with.
Of course I want to be wrong on that statement, I don’t actually want guinux to drop Pamac.
The thing is that a significant part of the community in Testing and Unstable actually don’t use it at all. It’s hard to gather data and improve the software when the package manager made in-house is not even used by the testers themselves.
That is a huge flaw in Manjaro QA in my opinion. In addition to the lack of people on development branches, people who use Testing and Unstable are generally using tools and ways to upgrade their system that are not used by the average joe in Stable. I cannot blame them to follow good practices of course, but it means that we can get really unexpected results in Stable.
It is interesting to read about potential smoking guns here possibly pointing towards Pamac. It makes me wonder… did any of the [Plasma] users here who have posted about “disappointing” update outcomes when doing it graphically, use Octopi / would it be equally [potentially] susceptible as Pamac?
I have two Testing VMs. Used to be one, but recently i cloned it. After reading this interesting discussion, i think from now on i shall keep using tty for the bigger updates in one, but revert to Pamac for all updates in the other… then report back if/when the sky falls in.
But if it’s really that, damn, I don’t know how it could actually be fixed outside of ditching systemd completely for an alternative way (which won’t happen anytime soon)(btw, I’m neither pro or anti-systemd, don’t start a “systemd is satan himself” thread please) or hoping that systemd figures out a way to handle systemd upgrades with more stability.
I mean, we won’t just run the whole Pamac GUI process as root just not to use Polkit.
If that’s the case then pamac cli may also be affected. My x crash last week was on pamac cli and may even affect users in TTY as @Hipstermay have seen? Then you’ve got these users who were probably all on pamac gui. But before simply blaming pamac, the question is why ~1/5 users seem to be affected on pamac – system encryption?
I need a somewhat-workable system so I’ll use my own method of logging updates per pacman in x.
So, I have to take more care when there is an update in dbus or systemd? I go to a tty when appears in my pamac-gui a systemd update, now have more one, dbus, in my case, dbus-x11
I see no problem in doing this, btw