[anthonj]

I cringed hard when some people started to make pacman wrappers that could install from AUR directly.

I've installed stuff from the aur before but most of the times I prefer to skip the middleman and just navigate to the project website. A premade pkgbuild is not convenient enough to take the risk of typoquatting or the tactical npm or pip dependency.

[OJFord]

`yay` (one such wrapper) shows me the PKGBUILD diff on every update. The first time I install something I verify the URL, and check any install script etc. seems sensible; the vast majority of subsequent updates are changes to just version number & checksum. A typosquat attack would be very obvious.

(It's a bit vulnerable to it on first install, but so is 'just navigate to the project website [and click download]'.)

[anthonj]

But it's one middle man less.

Git repo have been attacked other times in the past, but a 500/1000 stars project still sounds more trustworthy than a user repository managed by randos with a couple of upvotes. I still use the aur for simple cases, but when I see aur packages depending on multiple other aur packages I immediately leave.

[feelamee]

and how many of others do the same? At least I'm not.. Happily I have only a few aur packages

[OJFord]

I'd recommend that you do – it's not very taxing, and if you only have a few then you won't even be doing it much. I'm not auditing the program code itself (where even available), literally just checking that the AUR package actually installs what it says it does/I expected.

[cromka]

Does it also show each patch involved?

[OJFord]

It shows the overall diff since last update, not patch-wise. But it does show any extra patch file, install script, etc. – not just the PKGBUILD – if that's what you meant.

[gpm]

The manager I use (paru) does, I'd be surprised if yay doesn't.

[Charon77]

It does, but there's a y/n question of whether you want to see the patch

[zenoprax]

People continue to criticize Arch for being elitist or gate-keeping to keep casuals out but there are clear benefits by not allowing dangerous things to be simple. This is true in many aspects of life.

After using Void Linux I switched to `aurutils` to get a similar separation on Arch. I can easily maintain a local AUR repo by compiling/making my own binaries and can use `pacman` to install and manage them which improves the upgrade process overall.

[recursivegirth]

> People continue to criticize Arch for being elitist or gate-keeping

I have the complete opposite experience. Arch makes it easy to get in and get hacking right away. Their beginner guide's on the wiki were a gem 10-15 years ago... made it super easy to get up and running. I don't have the time these days to tinker - but boy do I love some Arch.

[Grombobulous]

For me, this tradeoff isn’t worth it. I didn’t switch to Linux so that I can waste time going to websites and clicking “download” to update my programs like a Windows user.

The pacman wrappers you mention are crazy, though.

[anthonj]

I get it, but you only need to do that for the odd cases of packages not present in the official repo (not that common at all for me at least).

Also if the software is downloaded in the form of a git repo, you only needed to checkout the new tag and rebuild, don't need your browser at all.

[mananaysiempre]

You then get the advantage of the OS’s package manager accounting for everything, however. It’s quite nice to not wonder whether there’s random stateful detritus throughout your system and what it might be affecting. (OK, to be honest there still will be, but much less of it, and a greater part of it will be attributable.)

[bitmasher9]

I think the existence of the AUR puts less pressure on the official repository to have all popular software.

[saghm]

I think it's also a bit of a testing ground for the main repos as well. I maintained the `ruby-build` AUR package for a couple of years after the previous maintainer wanted to step down, but they eventually added it to the main repos and now it's maintained by one of the official people. (I don't recall ever having to do more than paste in the new release tag into the PKGBUILD each time and then generate the new .SRCINFO and checksums in terms of actual maintenance, although I'd test locally first before pushing of course).

[bitmasher9]

I’ve seen automation scripts for this process of updating packages.

Makes sense that the most popular AUR packages will be candidates for the main repo.

[saghm]

I only saw automation around this for the first time earlier this year when noticing that a package was multiple versions out of date and tracking it down to a bot (in the pre-LLM sense) on Gitlab for the package that gave a false negative on a version update due to the format of the upstream git tags changing (either they added a `v` to the beginning or removed it, I forget which). My takeaway from that experience is that while automation can be nice, I'm not convinced that the benefits outweigh the potential for bugs like that if it relies on invariants like git tags that are realistically not something that all upstream maintainers are going to be pedantic about keeping standardized.

I understand that having a relatively small number of people maintaining a large number of packages makes it burdensome to manually update everything, but on the other hand, nobody asked me before promoting the AUR package I maintained to the main repos, and I would have been happy to keep doing it indefinitely! I'm not a "official trusted contributor" by any means, but I also know that I would have kept doing what I already did for years in exactly the same way without any issues, so I can't help but feel a bit like like a known good with hypothetical risks was thrown away for something that will produce at best the same results with less severe but more concrete risks. I wish I had a solution for not getting stuck at that local optimum, but incidents like the one in the article will only make it more of an uphill battle.

(edit: to clarify, I'm not proposing that the package should have been left in the AUR, but that I wish there were a way for them to have just let me keep maintaining it as an "official" package. Maybe something like the kernel model where someone trusted could vet the PKGBUILD updates I do and decide whether to merge them or not rather than doing the same but with a bot, and then maybe not noticing that the bot is silently failing...)

[BobbyTables2]

AUR and similar repos for other distros scare the hell out of me.

Tutorials using them are so widespread… Start feeling like a weirdo for not wanting to give an unknown rando full indefinite root access to the system, with virtually zero peer review… all to install one version of a package where updates are undesired or infrequent…

[KetoManx64]

You don't have to. The AUR is just a bunch of PKGBUILD text files, which if you don't feel competent enough to read and understand and trust, you can create your own local versions of and install from. It's just a recipe file that says download a program from this github URL, make sure the hash matches and then extract it and move the files to system directories.

[pixelpoet]

> typoquatting

Perfect demonstration!

[mqus]

This sounds like your update process is quite involved then. Or do you just not do it?

[anthonj]

I only have a couple of things in /opt/ and some manually installed fonts, and vim plugins in my home. Everything else that I don't use often lives in the original cloned git repo in /home/projects and never really gets installed.

Of course the process breaks down for a large amount of packets, but I've never been in that situation. In part because the official repo is already large, and in part because I like minimalism.

If that even became an issue, I would manage a personal set of pkgbuild probably.

[qudat]

I don’t bother with wrappers, why does it need to be easier than git clone + makepkg -i?

Then I just update when I need to update

[beej71]

The wrapper will give you a nice diff of what changed. You can do that by hand, too, though.

[Charon77]

Wrapper is really helpful for every time you do pacman update for official repo, you should recompile all of the AUR repo as well, otherwise you'll be in the land of 'partial upgrades'. Some packages don't complaint too much, while others do