Hi, I'm a gen Z regular AUR user too. On Sat, Jun 13, 2026 at 07:23:37PM -0500, nathan sasser wrote: > Will note that I'm not familiar with mailing lists. (I'm gen Z and have > never touched this before) But looking through this, I have a few ideas, > some for the AUR's side, others for the AUR helper's side, and some others > that I'm not sure which side would need to contribute to implement it. > > (1) 1: My first thought was that for packages that are orphaned and are > also EOL or otherwise dropped by upstream i.e. not the AUR publisher, but > the developers. The PKGBUILDs should be made read only and unadoptable > without confirmation of a fork or the upstream devs picking it back up. > Seems extreme I know, but it seems a good amount of the packages that are > orphaned there (that aren't git packages) are for packages that are EOL by > the original devs or were for stuff that was since merged into mainline > versions.
In most cases, upstreams won't care about maintaining it, even if as simple as giving a nodding yes. Furthermore, the value of the AUR lies in how easy and free it is to make contributions. And a malicious maintainer could easily behave normally for a while, submit packages, make useful-looking updates, and still introduce malware later. Therefore, the proposed rule would mostly add friction for good will contributors without much improvements. -- Best regards, Xuelin Yang
