Just as an example, this guide suddenly assumes that "yay" is installed. Even though AUR helpers like yay aren't officially recommended by ArchLinux and also aren't trivial to install.
The design decisions around AUR befuddle me to this day. It's utterly arcane in how to use it. Or rather it feels like it wasn't designed at all and simply evolved.
I highly recommend people to use "yay" and similar helpers that make a lot of the problems simply go away.
The AUR makes either perfect sense or no sense depending on what you think it is. If you think it's an extra repo with more software, then it's a bit odd: Why no binaries? Why the antagonistic view of AUR helpers? Heck, why doesn't pacman just have an option to automatically use the AUR? Just add it as another repo next to extra. On the other hand, there's another viewpoint, where the AUR is what happens if you provide a free-form place for random users to post build scripts. Not packages, really, just "here's the commands I used to build this software on Arch". In that view, you're not expecting a streamlined experience, and binaries are a ridiculous idea; you grab someone's notes, read them over, and if they seem reasonable enough then you execute them (because the notes came in executable format). Or if they don't quite look right, you edit them into shape and then run them, and that's expected because this is just a way for a bunch of hackers to pass around suggested build steps.
And to be clear, I think the AUR certainly started as the second thing, but it's often viewed as the first, and maybe it even should be the first thing. But if you assume it came from the second option then all its design choices make sense.
It's really only meaningfully used as the first thing by virtually anyone.
Arch's whole identity as a distro is that of a coworker who is capable and competent at all the most useful aspects of his job whilst being completely useless at things which ultimately don't matter so you ignore his body odor, taste in music, and mismatched socks.
Nobody obtains security by watching the package script flash through their terminal just like nobody gains anything useful by doing a manual install at the terminal. These don't matter because you can use a script to install arch and use a helper script the same way you use apt.
> I think the AUR certainly started as the second thing, but it's often viewed as the first, and maybe it even should be the first thing. But if you assume it came from the second option then all its design choices make sense.
People who cite the AUR as a major reason to use or prefer Arch (which seems to be a lot) definitely see it and use it as the former. If it's not that, pretty much all of the package availability arguments in favor of Arch disappear.
(Which is fine— I don't think package availability arguments are very good when it comes to distro selection in general, except for non-technical people and absolute noobs.)
I've always thought it was more for developers. You can get something into AUR easily, and it is basically the basis for a real package.
So low effort for developers.
Meanwhile I think the high effort for users of AUR is an appropriate barrier to entry.
Every dangerous thing I've seen in life benefits from good situational awareness, and all the "learn makepkg" stuff plus "can't be root" seems to match the learning effort to the risk.
I think it's great. You clone a git repository which is amazing since you can just pull in new commits to get updates. Then you read and understand the PKGBUILD. When you are satisfied that it's not malware, you basically just run makepkg and it does everything. Then you vote on the package so that it's more likely to be included in the official repositories in the future.
Depends on what you mean by "community". There used to be a repository named "community", it is now called "extra" and it is indeed an official repository.
It is maintained by a group of trusted users who need to be sponsored by at least two other maintainers. This creates a web of trust rooted at the Arch Linux developers.
The Arch User Repository is what I consider to be a "community" repository. It is essentially the programming language package manager model. You create an account and push whatever packagers you want.
