PacUI removed from AUR

Got removed from AUR, RIP.

1 Like

pacui was removed from the AUR on initiative of Alad Wenter and Eli Schwartz (both trusted users of arch linux). the following reasons were given for this removal:

  1. pacui performs partial updates. as reference, a link to this forum post was given.

  2. in order to install packages, pacui disables signature checks. as reference, a link to pacui’s “trying to update system without checking keys” part was provided.

  3. pacui has questionable operations. as reference, a link to the “fix pacman errors” option was provided.

  4. pacui overwrites bootloader configuration. as reference, a link to the “sudo mkinitcpio -P && sudo grub-mkconfig -o /boot/grub/grub.cfg” command was given.

  5. pacui auto-installs AUR packages using --noconfirm via a race condition. a link to the “force update aur” option was given.

  6. pacui autodeletes journalctl logs. as reference, pacui’s “cleaning systemd log files” part was linked.

  7. pacui downgrades packages using -Rdd. a link to “roll back system” option was given.

besides the technical reasons listed above, their criticism in their own words:

Seems to be aimed at Manjaro going by the amount of partial upgrade it runs (e.g. [6]) and weird stuff like “update systemd first”. Former alone makes it unsuitable for inclusion in the wiki.
[…] – Alad (talk) 09:50, 11 June 2018 (UTC)

[…] Sometimes I think I have way too much fun reading peoples’ AUR helpers.
Also goes to show yaourt is in fact not the worst thing out there.
– Eschwartz (talk) 20:18, 29 July 2018 (UTC)

Well that seems unpleasant…

What do you plan on doing? Shall you try to meet arch linux standards or focus on manjaro?

1 Like

here are my answers:

  1. if pacman cannot update the system in a normal way, there are multiple steps taken in order to fix this problem. if your keyring is broken and your system clock is set completely wrong, you are not able to update. the 1 partial update is done as an attempt to fix this problem.
    if the next update attempt (without key signature check and possible manual intervention by the user) is successful, the system is not left in a partially updated state. however, if this still happens, the user is instructed how to continue.

    even if the worst case happens, i do not think that having 1 partially updated package on your system is that bad: ntp is not a critical package (and no critical packages depend on it).

  2. if pacman cannot update the system in a normal way, there are multiple steps taken in order to fix this problem. if your keyring is broken, you are no longer able to install any freshly downloaded packages. in an attempt to fix this problem, key signature checks are temporarily disabled and your keyrings are reinstalled. because i cannot do more partial updates here, pacman -Syu archlinux-keyring is being used.
    i have made sure that key signature checks are ALWAYS enabled again.

    if you know any way of automatically fixing keyring problems without temporarily disabling signature checks, please contact me or do a pull request in pacui’s github page.

  3. with 1. and 2. above, it is impossible to comply with the arch linux philosophy and do any form of automated fixing.
    maybe, i should stop trying to do any automated fixing and instead display a text like “RTFM”?

  4. pacui’s “edit config files” option provides an easy way to edit configuration files of your system. a file, which can be edited is /etc/mkinitcpio.conf.
    as the arch linux wiki instructs, the initramfs needs to be regenerated after a change in the /etc/mkinitcpio.conf file.
    IF the regeneration of initramfs is successful, /boot/grub/grub.cfg file is regenerated, too.

    edit: in order to not break non-grub systems, the user is asked, whether to regenerate initramfs and grub.cfg or not:
    thanks for this tip!

  5. this has been well explained in pacui’s help page:

    yaourt -Syua && yaourt -Syua --devel --needed --noconfirm
    The first command only updates AUR packages with updated/changed 
    PKGBUILD files. This gives you the chance to check these 
    updated/changed PKGBUILD files.
    The second command forces a reinstall of ALL your developmental AUR 
    packages (i.e. all git, svn, and cvs-packages). These kinds of AUR 
    packages are usually never updated/reinstalled with a simple 
    "yaourt -Syua". The "--noconfirm" flag is used in a secure way, because no 
    PKGBUILD files have changed since the first command got executed.

    unless the aur helpers do not update any development packages when used with the -Syu (or similar) flags (even if their PKGBUILD files has been modified), i still think that “–noconfirm” is used in a secure way.

    edit: this was solved in post number 50: PacUI removed from AUR

  6. pacui deletes journalctl logs (except for 50mb), when the user wants to clean their system. this is an extra option and NOT part of the update routine.
    a sane user would never clean their system, if there are major problems.

    as an example, i have just cleaned my system and about 400mb of journalctl logs were removed. however, there are still enough left to do some error hunting should anything happens:

    ~ > journalctl | wc -l

    i do not see a problem in cleaning some logs on request of the user as it is done here.
    i assume that the user wants to clean his/her system when the “maintain system” option is called, hence old package versions and logs are deleted in a conservative manner.

    however, should you disagree, i would like an explanation why it is necessary to have more (how much more?) than 100k lines of journalctl logs.

  7. this criticism is completely right.
    i have removed the -Rdd in the latest commit:
    thanks a lot!


i do not feel that all criticism is done in a constructive manner:
they insist on arch linux wiki recommendations, instead of suggesting how to have the same functionality in an arch linux compatible way,

however, i am open to suggestions how to improve arch linux compatibility of pacui in any way, but i do not want to sacrifice major functionality for it.

a great example is a broken keyring: according to them, i should refuse to solve this rather simple problem automatically and tell the user to user to RTFM.

what do you think about a poll how to continue?

i would really like some feedback on 4-6. i see potential for some improvements there.

If I may…

  1. This is a sensible action, I don’t find it dangerous at all, mostly “proper” I would say
  2. The --noconfirm feels like a “comfortable but with potential danger” option. If AUR can be updated without, there is nothing to loose (I guess, unless I’m missing something) except time(?) and ease. It can be considered an advanced option, so a user should be “forced” to do it manually, to ensure he knows what he’s doing. Maybe you can omit this…
  3. About journal logs, you might make it ask (or with options) for the remaining HD space (MB/GB), logs should be kept
1 Like
  1. as this post explains, i think --noconfirm is used in a safe way here.
    can you describe the “potentially dangerous” option you talk about?

    if there is a situation, in which this pacui option is dangerous, i will change it.

  2. i could create another environment variable, which overwrites default settings…
    what are sane default values here?

    maybe, instead of focusing on the log size, deleting all logs older than 15 days is better?

1 Like

In general, you could add simple yes/no dialogs that explain the “unsafe” options and allow opting out of them. Like "action y failed because of reason x. You can possibly fix the issue by running these commands: … Would you like to do this? (Y/n)

I find trimming the log not that dangerous, but I’m not sure package manager is the best place for it. I think it would suit the initmenu in bmenu better (btw, I’m using pacui as a submenu in bmenu).

Maybe they think that user somehow checks the sources as well as the PKGBUILD? I think this action has reason to exist (git packages with unchanged PKGBUILDs), so I would not drop it entirely.

1 Like

nice idea.

i do not like interactive elements in the rest of pauci, but “fix pacman errors” option could be the right place for it.

i have to think about it a little…

it got created, because people complained in the forum about a full root partition. limiting the size of the log seemed like a good idea, then. having something like that in a “maintain system” option is not 100% right, but maybe not 100% wrong either.

i know. i test bmenu from time to time.
i thought about a redesign of pacui’s title “PACUI - PACKAGE MANAGER”, but it would break visual styling with bmenu. so, i kept the title.

maybe you are right:
yaourt -Syua
yaourt -Syua --devel --needed --noconfirm
the first command updates all aur packages with changed PKGBUILD. here, the user can check sources and script commands to build the package.
the second command updates development packages, whose PKGBUILD file has not changed. therefore, there is no need to check sources, if you have already checked them during installation.


I think you are correct, I did not understand it at first, sorry (not so fluent on this). Then I guess this should have been discussed with you, if this is something the Arch universe finds it normal, before adding it to the reasons.

Overwriting default settings is like a manual user intervention (own system), which is nominal, considering PacUI as a System Tool. Maybe (just trying to understand here) they consider it only a Packages tool.
Sane defaults IMO are whatever the System Admin decides, so a user with admin privs would fit.
I would say that it is better to focus on log size, than time, since it happens that a system is down/power-off for a long break and the info may be valuable after an action (update/install) on next wake-up/boot.

1 Like

i was never contacted nor have i ever received any constructive answers from them, despite being as polite as possible.

thanks for this piece of insight!
i have felt on multiple occasions that they fail to comprehend what pacui tries to achieve. instead, they criticize it purely on its code (by comparing it to recommended pacman practices).

they have probably never read pacui’s help page…

I usually say this:

Even a criminal is asked to explain about his actions, before a jury gives a verdict…

I struggle to not think that this is a kind of “war”. I will still try, out of respect to Archlinux really great distro.

this was not meant as an attack.
(and your way of quoting does not help it either :wink:)

i am rather disappointed. here is probably a better expression of the same feeling:

btw, i like arch linux.


Sounds like academia at work to me… “never have so many, fought so hard, over so little…” Or that great medieval discussion on “How many angels can stand on the head of a pin…” I personally find pacui very useful. Thus far I have not noted a world catastrophe resulting from its use… :blush:


You are right, just one little correction Re “academia @ work”. It’s a spirit of modern academia.
These guys are trying to mimic a corrupt government special forces, essentially doing policing in tyrannical and unreasonable way. Looks like AUR helpers war just provoked them to show administrative powers over Arch community in a quite perverse and inconsistent ways. Nobody from users community had (documented and really conceptual) problems with different system helpers out there. There were ample freedom of choice, many switches to find the best suited setup for everyone. Heck, I even have /usr/bin/yay -Syu --noconfirm system timer running for months without a single problem on Arch!

IMHO if this dangerous trend continues and the decisive forces behind Arch do nothing to stop these guys, we might be soon in a situation of Arch decline, AUR repository splits or even death.

I guess it is more like modern governments… :wink:

it’s time to congratulate Arch police with #metoo badge :rofl:

As self proclaimed Arch “special police” guys are deliberately arrogant I don’t think you could prove anything to them. Of course you can introduce an extra couple of environment variables like PACUI_ALLOW_UNSAFE_OPERATIONS and PACUI_SKIP_CONFIRMATION_OF_UNSAVE_OPERATIONS, but I doubt it’d make any difference. It’s easier for them just remove the script than to evaluate it thoroughly and have an headache of classifying it among AUR package helper utilities. I think the current 50 MB log truncating is just better than a row count based one.

Assiming @excalibur1234 didn’t get any reasonable response I’d suggest to put pacui and other useful packages into Manjaro Users Repository (MUR).


pacui is already in the manjaro repositories.

additionally, the development version can be manually installed.


Forum kindly sponsored by