AUR is definitely not the reason people choose arch haha
Fellow Linux folks, this direction is one of the main problems and you know it very darn well.
Nah, it is my MAIN reason using Arch-based distro. If not because AUR, I should still using rock-solid Linux Mint… lol… 😅
Asbestos undies on.
I don’t think AUR is a feature, but more of a hazard indicator. If the distributor isn’t packaging so many important things that most users have to turn to external services regularly, they’re lying down on the job.
I think you misunderstand the typical use case for the AUR. It’s generally used to install fairly niche software that might fly under the radar of distro maintainers. For example, I have CoreCtrl, a utility for managing AMD GPUs, on my install via the AUR. I’m not aware of any distro that packages it currently because it’s just too niche of a use case right now for maintainers to pay it any mind.
I think initially it was because the distro repositories were fairly small, agree now it is often a lot of niche stuff now which is one reason people who don’t use the AUR don’t really miss it either.
That package is in Fedora and Debian testing/Sid and the next Ubuntu. There is also an Ubuntu ppa for the and it’s on the opensuse build service.
I guess I was baffled when FVWM of all things was an AUR package. To me, that’s something that’s been available in the mainstream package set on almost any full-sized x86/x86-64 distribution made in the last 25 years. I suppose it’s not popular these days, but you sort of expect it to materialize because it was checked into auto-build processes in the late Clinton administration and never removed.
Yeah if the AUR can stop me from having to compile even just one package from instructions on a github page (like with corectrl, which I also use lol), then it’s enough for me to keep using arch. I will say, AUR is in the normal arch repo I think? But there’s other packages I’ve used in the past that I can’t find in there, like specific versions of mangohud or gamescope, goverlay, etc.
AUR still means you gotta compile sometimes, but it’s so much less of a hassle to just search the AUR and hit go then to mess around compiling something manually.
AUR is really not that great? Who moves to Arch for it? It’s been my main OS for I don’t even know how long but AUR has been my primary pain point. PKGBUILD is cool and useful useful. AUR however, is untrusted (or rather shouldn’t be trusted), often out of date, sometimes requires compilation, and doesn’t even have any good pacman wrappers since yaourt (that I’m aware of).
Am I missing something?
AUR however, is untrusted (or rather shouldn’t be trusted), often out of date
So basically like a PPA which are used by many users of Ubuntu. The only difference is that the PKBUILD files used to build the packages are easier to check than the final packages in a PPA. And that’s exactly what is a big advantage for me.
sometimes requires compilation,
This is often because a project does not offer ready-made packages that can be downloaded from Github, for example. There are also people who do not trust ready-made packages from unknown third parties. I wouldn’t necessarily download and execute a binary file from a Dropbox of a user I don’t know. Compiling is the safer way if the source code is downloaded from a more trustworthy source.
and doesn’t even have any good pacman wrappers since yaourt (that I’m aware of).
Personally, I don’t think aurutils, paru and yay are bad. I currently use aurutils myself. But as far as AUR helpers are concerned, everyone has their own preferences. That’s why there are so many ;-)
doesn’t even have any good pacman wrappers since yaourt (that I’m aware of).
paru is cool
I have an hard time moving out of yay… TBH if AUR could be installable from pacman it would be awesome
Yeah, AUR isn’t great because it’s engineered as a second class citizen given the necessity of third-party tools like yaourt, and that the whole process of installation can’t be done directly through the first-party tool (pacman), such that updating the main packages can trivially cause third-party packages to suddenly stop working. ArchLinux offers just one way - their way - when it comes to dealing with software versions and if the user happens to depend on some thing they want to keep around, tough luck, and hope that future upgrades don’t force a breakage that requires a recompilation which may no longer work.
That runs completely opposite to Gentoo, where the first-party repositories are defined the exact same way as third-party repositories, and that updates to first-party libraries generally don’t immediately break existing binaries because the distribution was built with recompilation requirements from upgrade breakages in mind. Since third-party packages are treated no differently (no second class citizen treatment), their first-party tool (emerge) can manage the complete lifecycle of “third-party” packages in the exact same manner (as opposed to needing any third party tools to manage the build). This alone reduces the mental bandwidth for the end-users that are managing their set of required packages for their systems. All this flexibility is ultimately part of the various reasons that got me to switch from Arch back to Gentoo.
I admit AUR was a huge reason why I made the move to Arch. But with Flatpak gaining more and more traction, the benefits of AUR are shrinking fast.
A subset of AUR PKGBUILDs are downloading a prebuilt desktop application binary packaged for another distro (deb, rpm, tarball, appimage) from upstream and then unpacking it. Those packages are trying to solve some of the same problems as flatpak, distributing a generic desktop binary but often do it worse and people should be weighing the alternatives. More broadly AUR packages aren’t comparable with flatpak but some are.
The AUR still has a lot of niche software that hasn’t been Flatpakked, but yeah. Flatpaks are way more convenient, especially for large software where AUR compilation can take a long time.
What’s wrong with librewolf-bin? Would you choose the Flatpack or the bin from the AUR?
Agreed. DaVinci Resolve Studio and Blackmagic hardware drivers are examples of that kind of niche software that I use on a regular basis. The only supported route for that stuff is RHEL/CentOS, and those don’t seem particularly well-suited to my main machine’s other purpose, which is games. If someone’s already done the legwork to solve the problem for Arch, and the build files check out, why reinvent the wheel?
Additionally, it’s the only distro I could get Resolve Studio working on with an AMD GPU consistently.
For the most part, though, the official repos and Flathub give me what I need.
Agreed. DaVinci Resolve Studio and Blackmagic hardware drivers are examples of that kind of niche software that I use on a regular basis. The only supported route for that stuff is RHEL/CentOS, and those don’t seem particularly well-suited to my main machine’s other purpose, which is games. If someone’s already done the legwork to solve the problem for Arch, and the build files check out, why reinvent the wheel?
Additionally, it’s the only distro I could get Resolve Studio working on with an AMD GPU consistently.
For the most part, though, the official repos and Flathub give me what I need.
I tried arch and got rid of it after a couple months because of the aur. Do people just not check out what they’re installing? Every time I wanted a new software i’d have to check it out to make sure it was legit, and every time I updated i’d have to check the diffs to make sure it was still legit. Otherwise, who knows what you’re actually installing.
Main reason I like the AUR is for really niche packages that aren’t in any main repos. Smaller github projects, forks of main projects that fix bugs, basically anything that you would otherwise have to compile from source is on the AUR. And while you still might have to compile it, it’s all setup and managed for you, which I really like.
What does the AUR get you that a:
../configure --prefix=(pwd)/install make make install
doesn’t?
