AUR idea, suggestion, comments

Wont it be obvious when you run EOS updater and it asks you to install from the AUR?

This happened not too long ago for me with one of the virtual keyboards.

What happens if a package drops to AUR but you only ever use pacman and not yay? Just get’s removed? Maybe the default update in EOS should just use pacman?

Anyone think caffeine-ng from AUR is a ‘bad’ idea or concept? I can’t stand my desktop dropping out into a limbo state because I didn’t move the mouse soon enough then having to log in when it goes into standby mode. Some packages in AUR work well, but nobody is addressing the the purpose to have them in the first place. IMHO caffeine-ng should be available with every desktop. If you don’t want it disable it in the menu. Software that is functional has a place. If it’s being developed it should be addressed as such and be monitored by the dev’s. AUR isn’t all bad. Too much attention is focused on the operational shell of a DE and not the software that can be used that only a few people are attempting to make available for everyone to use. Yes, there are bad actors out there. Policing your software is the best bet and a good practice. It’s not a good idea to throw out the baby with the bathwater. . . . Another app radiotray-ng. . . . it’s nice to have music off the Internet on your computer after starting it up. Just my opinion. . .

Rich :wink:

then run
eos-update --pacman

–pacman Same as --helper=pacman. Default. (Note: pacman does not support AUR directly).

See eos-update -h for more helpful info.

Is this good practice though or overthinking it?

I don’t use eos-update I have my own update script I use. I would only use it this way if I had no packages from the AUR I do so I don’t recommend running out of date packages on your system.

FWIW, I can see people are all over the map with the topic, conflating issues, carrying a torch, etc. None are bad, it’s just impossible to untangle much in a linear thread. Issues I see involve personal responsibility, arch limits/ limitations, distro responsibilities/services/ideas/desires.

Arch could, can learn from other distros if it wishes and choose new (perhaps tried & true) options. The same applies to EOS. As Linux users, we can use distros which serve our needs well/ better/ worse.

The question I originally hoped to hear discussed was whether the AUR problems meritted a re-examination of the arch/ EOS ecos structure & offerings.

The sense from this thread that I gather is… nope they don’t.

Nothing wrong with that. But at the end of the day everybody is aware how the situation could be improved. Usually the required resources (voluntary or paid) are just not available. Arch gets some love by Steam, but Steam isn’t particularly interested in the AUR situation. Most of the other money goes to distributions used on servers and Fedora as RHEL testbed or Ubuntu.

If you want to go a step further you could pull a few popular AUR packages into the distro repo - like e.g. CachyOS. But that again runs into a resource issue for EOS and also raises the question if it is even in the spirit of EOS.

I’m sure people will be thrilled to know that I have no longer ANY AUR installed software. Such are the advantages of dwm & i3wm on x11. :upside_down_face: From an opinionated old guy >>>> :old_man:

I came a bit late to the party, a lot of ground has been covered already.

With respect to your original idea though @manyroads, the existing votes and popularity metrics in the AUR, already serve a similar purpose.

Popular packages are likely being used by more individuals, and hopefully a large portion of those are paying attention to changes to the packages. Simply put, if something dodgy is going on, their’s perhaps a higher chance someone is going to notice.

Now to caution though, that doesn’t mean it’s guaranteed safe, only that there’s a larger community around it who may notice a malicious change. Such a discovery would likely only occur after compromise. The Axios NPM supply chain attack in March this year is an example of how even a trusted and widely used package “with over 100 million weekly npm downloads” can be compromised.


I suspect this is a misunderstanding?

In order to maintain a package on the AUR, one needs to register an account with the AUR. All package maintainers are registered users.

If you’re referring to this somewhat confusing metric:

Registered Users      141946
Package Maintainers   69

Any of those “registered users” can maintain packages. The relatively small number of “package maintainers” there are recognised Arch community members with elevated responsibilities.

Requiring registration to simply download from the AUR, if that’s what you’re suggesting, fixes no problem at all.

Ah okay. My suggestion is anyway wrong, since I made it based on incorrect information, and I won’t be making any further suggestions regarding the AUR, since I’m fine with the fact that it’s my responsibility—and no one else’s—to exercise due diligence when downloading files from there. Thanks for the clarification.