linuxmemes

There's a lot of content packaged for the AUR that isn't readily available to people using less enlightened distributions.

I use Arch BTW.

Seriousposting: a lot of software just isn't packaged as deb or rpm because no one has taken the time to do it. The AUR is really fucking convenient as an end user. And yes, you should always skim AUR packages to be sure they're doing what they claim to do and aren't garbage, anyone can post anything. I have seen a lot of trash uploaded to the AUR.

Seriously, look at what the pkgbuild is doing on Arch and replicate it by hand on your distro of choice. That's all a pkgbuild is: a simple bash installation script.

True but dependency hell and maintaining updates for that is a headache I wish not to deal with.

timely updates

You mean I shouldn't git pull; git checkout HEAD; sudo make install every day?

Thanks, Now excuse me while I put a million compiler flags to optimse my program by 1 nanosecond and contemplate the reasons for human existence.

Later: how to uninstall this app?

Also great when you get some software as a deb for old Ubuntu and don't want the trouble of manually making it work on a new system. Just make an old Ubuntu distrobox.

I don't understand any of this, my windows install is on a 120GB SSD, it's full now and I can't update my graphics driver.

Very very very rarely some stuff on it is sometimes orphaned or outdated, but it's really fucking great to simply "paru" and the thing I want.

I consider myself relatively familiar with linux, people come to me when they have issues or need help setting something up

But compiling stuff from source? That still gives me headaches 😩

AUR is love, AUR is life 🙏

Depending on the software, you can use it inside an arch Linux distrobox with yay or some other helper

Some programs may use libraries or tools specific to a distributions package manager. For example, yay, an AUR helper/pacman wrapper. You would have a very hard time getting it to work on Debian.

Other programs might only include build scripts for a distro specific build system. For example, a program might skip using a Makefile, and do everything in the Arch-specific PKGBUILD.

Generally though, most software uses a standard cross-distro (or even OS) build system. In this case, compiling from source would be an option on any distro. The program might still only be packaged for Arch/NixOS/Gentoo (or others), as it is a very simple process to do so.

AUR maintainer for a few niche packages here. It's because it lowers the barrier of entry. Remember this is all a volunteer effort.

What do I do when someone running ubuntu reports an error saying the PKGBUILD doesn't work?

What if the program fails due to a different version of the kernel? (True story, only after 2 weeks of debugging I found out that the user was running Manjaro, which used a different naming convention for the kernel)

What do I do if someone reports a missing library dependency on fedora? Should I also package that library for fedora?

If I'm packaging drivers for specific hardware. I'm not going to install a specific distro just to fix your issue (sorry!). Most of my advice is given on a best effort basis. I made these build scripts for myself since I want native installs for all my software, and thought other people may be interested in them as well. If the responsibility of maintaining them becomes too overwhelming (like with your LUR case). I'll probably host these build scripts in a private repo instead.

I think it might be because of dependencies that might not be the same version on other distros

The AUR has more eyes on it though and can be more up to date. Getting OBS plugins "wrapped" was a pain in the ass in NixOS and they were out of date. But I'll admit it's a pretty niche example.

*only if you count different versions as different packages.

Not as easy or as convenient as yay -Sy appname