Hacker News Reader

Comment by anthonj | Hacker News Reader

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.

View on HN

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.)

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

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).

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.

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...)

Reply on news.ycombinator.com