I'm always puzzled how folks praise PKGBUILDs when it's mostly irrelevant for a regular user. Unless by 'PKGBUILD system' you mean AUR, a place where random people push random build scripts and other folks are happy to execute said build scripts locally, quite often without any real sandboxing or even a quick glance at the actual code.
They're not more "random" than developers of a lot of software you run. Package quality tends to be pretty good, I've only seen doubtful things once or twice in about a decade, and nothing malicious. Definitely haven't seen anything like the famous `rm -rf /*` in the official non-"random" nvidia package that was prepared and then shat into the world by nvidia's non-"random" developers.
They're the most accessable packaging building system, is why. If you're ever actually trying to install something (properly, i.e. not making a mess by just splattering files across the filesystem with 'make install') that isn't already packaged, you're going to have the easiest time with PKGBUILDs (basically, if you can figure out how to compile the software using the instructions for that, you can make a PKGBUILD. The same is not true for other package managers). So they're praised by power users who can manage that and by developers who don't want to learn a harder to use packaging system.
Well, just because it's not relevant to a regular user doesn't mean it's not relevant to me and people like me.
The regular user only installs software others have packaged.
I end up packaging software sometimes (maintain a few AUR packages) but my main use-case is being able to modify the packaging myself for private use, generally to apply custom patches or alter compiler flags etc.
Being able to do all of this easily without ending up with a pile of goop everywhere from `git clone thing && cd thing && make && sudo make install` is nice.
I'll take AUR over random blog articles telling me to add some obscure deb repository to my Debian/Ubuntu sources. At least AUR gives an accepted process to submitting and maintaining these third party packages. You can leave comments and read comments by others on a particular package. You can check the PKGBUILD which exists for every package and can be accessed in the same way for every package. And I do check every single PKGBUILD before installing some random package. AUR provides infrastructure and processes. It centralises the whole idea of "third party packages". Not having AUR just means everybody has their own repos for particular programs and no way for users to communicate in an easy and accessible way, which I think is pure insanity.
Honestly, I think AUR is one of the best things to ever come out of Linux, because it's not just a repository.
You act like the choice is either having a small official repo plus PPAs or a small official repo plus AUR, when the context of this thread is a comparison is with OpenSUSE Tumbleweed which has a large official repo (plus PPAs in the form of other OBS repositories if you really need them, but you almost certainly don't). A large amount of software that an Arch user has to use the AUR for is in the OpenSUSE oss repo that is supported officially and "tested" when snapshots are released (though the amount of testing varies with the software, of course).
Because it is. When using OpenSuse, I still had to go looking for packages that weren't in the official repos.
> plus PPAs in the form of other OBS repositories if you really need them, but you almost certainly don't
This is extremely presumptive and wrong. I find it very frustrating that any issues with these official repos is dismissed as "oh but you don't need extra PPAs ever". My guy, yes, I do. It happens way too often and it's very frustrating when it does, because the options for handling it in non-Arch based distros are completely insufficient and terrible.
But then again, what do I expect. Any complaints about Linux are pretty much always dismissed out of hand.
I actually prefer using Windows because Windows users generally aren't such arrogant pricks when there are issues.
what do you think "a regular user" of ubuntu/suse/fedora/arch/etc. looks like?
back when I was using arch I wrote pkgbuilds instead of configure/make/installing to my home folder. kept my ./local/(bin|lib|share) clean and meant I could update it easier or uninstall it with pacman.
As to runnning random build scripts, well I already do that anyway. Any software that isn't provided by my package manager requires me to run random build scripts from random people. I sure as hell am not reading through every line of code in say... trealla prolog before make-ing it.
An immutable rootfs distro should be a bit more resilient than the average Linux install. Not having to add any random repos to your base system is a great feature. When I run random build scripts I mostly use containers or VMs, that also works for the odd unmaintained but useful software that requires vintage Ubuntu LTS libraries.
> back when I was using arch I wrote pkgbuilds instead of configure/make/installing to my home folder. kept my ./local/(bin|lib|share) clean and meant I could update it easier or uninstall it with pacman.
yeah, and the number of people who use a non-android linux and aren't "tech savvy" rounds to zero. It is very weird to ask "what's in it for the regular user" with the assumption that "the regular user of e.g. SUSE" is the same as "the regular user of a computer"
With Tumbleweed (and probably Aeon) you can use factory/open build service to build your own packages. You could even fork Aeon or MicroOS and turn to that into something like a customized Arch Install that also benefits from whatever automated tests Tumbleweed comes with.
It's hard to give up the Arch PKGBUILD system though, it's an even simpler ebuild which was originally why I loved Gentoo so much.