PacUI removed from AUR

You if you have a package foo-git. I thought ‘yay -Syu’ wouldn’t update because the pkgbuild hasn’t changed(even though the source has). But if you did get a new pkgbuild, won’t it rebuild foo-git regardless of whether the source has changed?

If we are talking about a pkgbuild that hasn’t changed that we have used in the past to install from that has always pulled the latest version of code from a certain repository, the risk seems pretty much the same as the first time you did the original install. What is the situation that you would choose not to install that?

1 Like

You both didn’t understand the matter. The rationale for --noconfirm was explained at least twice.
And you both are wrong about it. You are wrong about it on a very primitive level - it’s annoying for you to be asked if you really want to build the package. @mandog didn’t understand that --noconfirm get’s applied for packages which PKGBUILD didn’t change.

1 Like

Call me a elitist its water off a ducks back. If elitist is caring for your distro of choice that is fine by me users that don’t give a monkey about the distro that feeds them and the damage they can cause if a package is compromised, that is not thinking of the end user that is compromising the end user in this case Arch users. What Manjaro does with it own packages is Manjaro business. what Manjaro tries to do with AUR packages is Arch user business.
If Manjaro users do not comply then its tough shyte the package will be removed the trusted users are thinking of Arch end users the same applies to Arch users in fact a Arch user would more than likely get banned, It is their user repro not Manjaro so you guys either suck it or use your own.

This isn’t really about Manjaro. Manjaro users have access to PacUI in the repos. This is about other AUR users having access to it.

1 Like

That is why it was removed from AUR it did not conform to what ever, If manjaro has it in its repro that is fine for manjaro users, complaining it was removed from AUR is just pointless.
But then I’m a elitist because I agree with its removal as I’m a Arch user it could harm Arch users.

I only use helpers when I feel lazy that also makes me a elitist according to one user so if that is the case i’m proud to be because I do things the Arch way when using Arch, but then I do things the void way the Artix way blaa blaa blaa but on the bright side I don’t get the pleasure of broken systems so that must make me a elitist as well, if you have that mentality.


Since the use of the --no-confirm flag keeps getting misunderstood and it is easier to change code than people’s perceptions, how about replacing the flag like this:

  1. get a list of AUR packages whose pakgbuild did not change
  2. pass that list explicitly to yay -Syu so that those packages get updated too

Maybe this would get around the problem? Not sure if it would work, this is just theory crafting just after waking up. But if you can get those packages updated without needing that flag, maybe you don’t have to deal with people not understanding why it would be needed.

Isn’t that the same thing as doing yay -Syu --devel --needed? Also, would changing that one thing even satisfy the requirements to get it back in the AUR?

Not sure. My idea was to circumvent using --no-confirm because people misunderstand and overreact to it. But it is only one of the requirements to meet I think.

absolutely not.

the second post in this topic contains a list of all points, which were criticized. and i think that criticism would not stop there, because there are other questionable parts of pacui (such as a circumvention of the no-longer existing “–force” flag).

my answers to all the points is available in the forth post of this topic. 1 point of criticism was correct while i question the validity of the other points.

if anybody can describe ANY situation, in which pacui’s code can be harmful, i am willing to change it.
there is 1 exception though: i would really like a way to automatically (possibly after asking the user for permission) fix keyring issues. it seems this cannot be done without violating any “guidelines” (see points 1-3. in the second post).

1 Like

This is just my outside perspective. But here is the way I see it.

  • You made a cool UI that automates & simplifies some things related to package management
  • Your package didn’t break any AUR rules because there really isn’t much in the way of rules for package content on AUR. At least not that I could find. Most of the rules apply to how things are to be packaged and named.
  • Two Arch TUs don’t like the philosophy of what your software does
  • They found reasons to remove it from the AUR

What can you possibly do in this situation except keep making the tool you want to make and a be a little disappointed it is no longer available to Arch users as easily?

I mean, half the arguing/criticism in this thread fails to even understand the concerns/situation.

In summary, ignore the whiners, keep doing what you are doing and thanks for making something to benefit the rest of us. :smiling_imp:


I think as Manjaro continues to evolve, there will inevitably be more points of differences between it and Arch, especially in aspects like the philosophy behind how a distro should be installed and maintained.

AUR was set up for the Arch users and community, with some Arch devs or key members of their community having oversight and control over it (as far as I can understand how it works).

So perhaps there is no choice but to accept that the people having control of AUR have veto rights over what they see as a package management and maintenance tool that promotes a way of doing things that they disagree with.

I accept that you have clear reasons for and responses to their objections over PacUI, but I’m no expert and can’t really comment on the technical aspects of it.

I just feel that since pacUI is found in Manjaro anyway, just leave it be. Come to the worst, have some github or gitlab page for it and if any Arch or Arch-derivative users want to use it they have to put it together themselves.

I see this happening more often in future if Manjaro continues to create tools specific to itself.

Even more strange for someone using Plasma on Arch: KDiscover has checkboxes for every update.
So a newbie user thinks, ah I’ll update Firefox real quick. Install just firefox but not the libicui18n it’s built with and end up with a broken install. All that without ever entering a password or kdesu’ing.

1 Like

i was wrong about my assumptions (from reading pacman and AUR helper man pages) how --noconfirm works. this was well explained by @zzorra on github in a pull request removing the --noconfirm flag here:

i have merged the pull request. the --noconfirm flags are gone.


I think it’s due time for an updated 2018 positive post from Mcrae on Manjaro’s achievements as a fork.

His posts are concerning pacman which is coincidental because of the state of package managers/AUR helpers. Couldn’t these problems that pacui deals with automatically via script be incorporated into pacman by default (non-AUR related, of course)?

# [Pacman-5.1 – Don’t Use the Force, Luke!]
# [Pacman-5.0 Released]

1 Like

Why Manjaro has nothing to do with Arch Linux his post was accurate at the time I think he also said in a later post that Manjaro security had improved which it has.
And why O why dig out old news for the sake of what, its not 2015 its 2018 so not relevant in any which way.

To understand where the original friction between arch and manjaro began from. History.

No their is no friction after the attempts to compromise AUR they have decided to check all packages in the AUR nothing more a Artix user had the same thing with a package of him I’m sure their are others to.


Fair enough. I’m an optimist as well.:+1:

No i don’t think so. But i’m a realist and spent years using Arch they are not as bad as some people make out. Go to Jasons web site to see how really helpful he is in real life. or Alans another great guy things are taken out of context for brownie points.

I think this change might be woth a major version increment. You could also simply try to create a new AUR package, update the description (Yaourt isn’t supported anymore).

Forum kindly sponsored by