Feedback on Pamac

[philm]

@SealOfAllSeals

Also just wanted to add, the new GUI looks amazing.

That depends on which desktop environment you are using. Some like the new libadwaita approach, others who use XFCE or Plasma don’t like GTK4 apps much, as they are harder to integrate to a non GTK based desktop. It is always an up and down.

@guinux

I introduced with libpamac 11.5.4, a way to make a so called Local Privilege Escalation that permits to a logged in user to grant root access.

@guinux whould that mean that 11.5.3 might not have the issue the LPE test code here uses? There are still some parts of the function pamac provides not working properly. I’ll try with an older code once again to see if that improves some of the usability overall.

[Olli]

@philm

There are still some parts of the function pamac provides not working properly.

in fact and this makes me wonder that this thread is marked as solved. pamac does not work as it should and it’s a essential part of manjaro.
we’ll see if the security-leak is closed now but i’m not considered about and the further malfunction/non-function of pamac is sad. but the most embarassing is that it wasn’t a priority for manjaro-devs, downplayed to a “small” issue". It isn’t

[philm]

I can confirm that the LPE got introduced via libpamac 11.5.4. Going back to libpamac 11.5.3 and a matching UI the exploit don’t work:

[+] 2nd DBUS call

method return time=1689402995.609837 sender=:1.199 -> destination=:1.198 serial=3 reply_serial=2

[*] Done. Calling boomsh in 10s!
Current user: manjaro
DONT ENTER SUDO PASSWORD WHEN ASKED. CANCEL!
[sudo] Passwort für manjaro: 
sudo: A password is needed
[manjaro@infinitybook Downloads]$ pacman -Q | grep pamac
libpamac 11.5.3-1
libpamac-flatpak-plugin 11.5.3-1
libpamac-snap-plugin 11.5.3-1
pamac-cli 10.5.1-1
pamac-gnome-integration 10.5.1-1
pamac-gtk 10.5.1-1

We know now more why that change was made that way, however we could have avoid that to begin with. Due to changes on how to check DBs libpamac 11.5.4 however became mandatory for pamac 10.5.2 and up …

[Olli]

@philm

however we could have avoid that to begin with.

to be honest. the mess started with introducing flatpaks and therefor the “needed” use of fakeroot. fakeroot has always been the “büchse der pandorra” and the use of it is toxic. this was the reason why i switched from ubuntu-related distros to others and btw. leaving fakeroot in the system is a bad tension. it might be needed while the installation-process for software-packages, but it should be removed straight afterwards. leaving fakeroot on the system is japanese-amok-style.

[guinux]

@Olli

the mess started with introducing flatpaks and therefor the “needed” use of fakeroot.

No this issue is totally unrelated to Pamac flatpak support

[wongs]

@linux-aarhus I’ve been using Manjaro since 2012/2013 (32-bit) and my 64-bit install has been running just fine since 2015. I don’t post anymore because I miss the chatty atmosphere of the old forum. However, I continue to use Manjaro, and do not talk bad about it.

I have resurfaced because this is a deja vu occurrence. There will be a series of problem-free upgrades and newer users will be happily announcing that the upgrades went smoothly and that this is the best distro EVAH and it’s so cool that it’s a rolling distro and they get the latest packages and everything else they need is in AUR etc etc etc.

Then you get one messy upgrade with problems for those who used pamac GUI, and you get outraged posts about Manjaro or pamac, and asking what’s the point of Manjaro if the user still has to use the terminal to upgrade. This has happened before and will happen again.

In my view, the reason for my problem-free Manjaro installs is that I recognise that GUI-pamac’s best role is to carry out easy search and one-off installs/removals AFTER the full system-upgrade has been carried out by pacman. Also, any AUR packages should not be upgraded together with the normal repo packages. Potential AUR upgrades should be examined in pamac after the pacman upgrade is completed, because not every listed AUR upgrade needs to actually be upgraded. Some packages are just deprecated main repo packages that have been pushed to AUR but which the user might not actually need anymore, in which case the right thing to do is to remove the package instead of trying to build that package from AUR. Sometimes you get users wondering why a AUR package rebuild is taking so long (eg python2 after it was deprecated), when it was an unneeded package that could have been removed.

I have seen from some posts in the past that some users want to upgrade everything in one go, and maybe do it all from the pamac GUI, because they may not know better. I strongly believe that’s a large cause of some users’ issues. And that’s at least partly because Manjaro’s website still, after all this time, does not disabuse people of the impression that Manjaro is a distro where one can always run easy one-click upgrades from the pamac GUI.

In the past, I made quite a few forum posts urging Manjaro to manage the expectations (I’ve used this phrase quite often) of users. And I believe I have suggested that there should be some commentary in the wiki or website about the fact that it might be better not to upgrade the system with pamac.

Don’t get me wrong, I’m grateful to @guinux for pamac. It’s a very useful graphical app that I use not just in Manjaro but in Anarchy/Artix (via pamac-aur). But like I said before, I don’t upgrade with it. I’m also grateful to the Manjaro devs for smoothing over things that might require manual intervention in Arch. But again, it’s not helpful to the newer users to think that that means no intervention is ever necessary or that one does not need to maintain one’s Manjaro system anymore.

I repeat, the phrase is “managing expectations”.

I really think it would be for the best to make it clear on the website that Manjaro will never be as easy/problem-free to upgrade as fixed release distros like Debian/Ubuntu. Some work may have to be done on the part of the user. That’s just the price of having an install-once, leading-edge Arch-based distro.

[Mirdarthos]

@wongs

I’m also grateful to the Manjaro devs for smoothing over things that might require manual intervention in Arch. But again, it’s not helpful to the newer users to think that that means no intervention is ever necessary or that one does not need to maintain one’s Manjaro system anymore.

And sorry for butting in here, but this, is exactly why I always recommend the use of pamac instead of pacman. Even for system upgrades. I use it myself for that, and it works like a charm.

_{But then, I don’t expect to be spoon-fed and don’t do updates the moment they are pushed.}

[medmedin]

It’s not a hate toward GTK4, but toward that evil LibAdwaita which is cursed and locks the app customization with that ugly embedded Adwaita theme.

[Olli]

but the actual problems raise up some more questions about potential security risks that are beyond the simple fact that an app isn’t working as it should.
actually there are some aspects that are questionable:
pamac has/had flaws that enable an exploit.
fakeroot is an app that is left on the system after installation although it enables everyone and everything to run as root.

there should be a general discussion about those issues where the problems can be named, described and workarounds are explained. something like a thread “Potential Security Risks and Questionable Applications”
i would appreciate such a thread but without a properly communication with the manjaro-devs ? it would run to middle of nowhere.

[wongs]

@Mirdarthos

But then, I don’t expect to be spoon-fed and don’t do updates the moment they are pushed.

I mean, you’re not one of those whose expectations have to be managed . But as a matter of interest, when you say you always recommend the use of pamac even for system upgrades, are you referring to the CLI command or the GUI?

[Mirdarthos]

@wongs

are you referring to the CLI command or the GUI?

I always use, and recommend the CLI. It’s just easier to copy-and-paste here, for support anyway.

@wongs

I mean, you’re not one of those whose expectations have to be managed .

*phew* that’s good news!

[Teo]

As a new manjaro user, i used a couple days of my vacation to read and learn, because it is a bit different from the ubuntu i was used with.

So after the last events, my personal strategy to balance between stability and rolling release, if it helps anyone:

• I reverted to kernel 6.1, which is actually from december 22…and my cpu is from 2021, and laptop from 2022, so it should be good supported (as good as possible, of course i have acpi errors…).
• I reverted to stable branch
• i kept the aur stuff to a minimum. Non of my AUR packages have Python dependencies, so i should be spared the rebuilding-circus May next year…Actually the only package that is a real program is rclone-browser. The others are a dictionary, udev rule, a service. These should be fine even with stable and never really need a rebuild.
• generally i use pamac. Aur enabled, but without aur update checks. Also, no snaps (that’s why i left ubuntu after all) or flatpaks. But i always click on the arrow to see the log! If there is any kind of problem, i solve it in terminal with pacman, mirrors, pacdiff, etc.
• i use the check-aur.sh script from the tutorial from archus-linux for aur update check. If there is one, i update aur with yay -Syu after i did pacman -Syu

I think that should be enough to give me a stable and modern system

[wongs]

@Mirdarthos

I always use, and recommend the CLI. It’s just easier to copy-and-paste here, for support anyway.

Hmm. May not help those who think using the command line is an affront to “user-friendliness”, and that pamac GUI should be used for everything.

[Mirdarthos]

Yeah, I know. But you can’t please everybody, can you?

My argument is, that if you really want to use Linux, you’ll be more than willing to get your hands dirty. And Manjaro makes it so that your hands get dirty, but not too dirty. a Perfect balance IMHO.

[Teo]

I call Manjaro “The next level after some experience with Ubuntu/Mint”
The level above will be pure Arch/Gentoo. Only for real Men with beard, hat, horse and 2 Colt 45 cal on the belt.

[Mirdarthos]

@Teo

Gentoo

Word of warning, from personal experience: that’s not for:

1. The faint of heart;
2. those with too little time; or
3. anyone with logic.

[Teo]

Lets wrap it up with a smile

[philm]

@philm

Going back to libpamac 11.5.3 and a matching UI the exploit don’t work

Hmm, I was wrong on that one. Seems even with an older version like 11.4.3 of libpamac the LPE was working. This means we have to rethink on how we use tmp folders, maybe check the code of our daemon and find a proper way. libpamac 11.5.7 acts now as bandaid until we figure it out properly, regardless if some functions are now broken.

[mithrial]

This might not be the right place, but you could do something like dnf on Fedora does, and download the databases per user and not per system.