Hi,
On 15/11/2023 15:21, Marcell Meszaros wrote:
Hi all,
Again quoting from the mail I am currently responding to:
Getting this automated in AURWeb itself would be a lot more helpful then
filling ~ 50k deletion requests.
I don't know where the 50k (50.000) figure comes from. I have filed more than
an order of magnitude lower amount of that during the last 3 years. I have also
learned from my initial mistakes and now I try to include a little bit more
information in each submission. Of course, I also try to be brief if possible.
I have to apologize as I misquoted, we have 2929 package requests found.
In total 59 pages, I accidentally quoted all opened requests that was
not my intention.
As the AUR has been a low policing zone for most of its existence, with no
pre-submission and during-maintenance code review gating, it is inevitable that
there is a huge amount of dead weight in it. With older versions of PKGBUILDs
still existing when a newer one was already submitted maybe due to VCS
repository migration from one type to another, or when one library gets
deprecated by upstream in favor of others.
During the last half year, I have focused predominantly on packages that
intended to be drop-in replacements of Arch repo packages but which were
defunct in one way or another. These packages had the highest exposure to users
while still being dead or unneeded, or just plain duplicates, new or old. In
consequence of their deletion, people have much lower chance of choosing
alternatives that are not proper or viable ones.
My other focus was dead/unneeded Python2 packages and also dead Python3 ones.
Of course I also filed many requests based on the long unavailability of the
sources and/or mandatory dependencies. (I usually check web.archive.org as well
to get a better picture on how far back the dependencies have been missing.)
Many of my requests follow similar, considered reasoning for similar cases that
are covered by filings from more veteran and well-respected AUR community
members like @a821 and @FabioLolix. I don't see why my requests in particular
would be less valid than theirs, if both theirs and mine have well-founded
arguments based on the same kinds of issues that make them choose to file those
requests.
We appreciate the efforts to clean up the AUR, as it has indeed
accumulated a lot of packages. What I tried to explain is that the
current approach is overburdening the team and the sheer amount of
requests overwhelms them.
With AUR having 86.000+ pkgbases and still keep packages from 10+ years ago, it
is not so outrageous to see thousands of requests filed.
I don't think that sanctioning legitimate community members like me in their
legitimate requests is a just and valid solution for a problem that clearly has
more adequate ways to handle.
One better way could be to try to involve more PM's amont the 64 in total, with more
regularity. Another could be to add issue category tags to requests, like in
GitHub/GitLab issues, so that PM's could more easily filter based on those. If such
system were in place, prioritization would be facilitated tremendously, e.g. severe
security and system integrity violations could be separated from e.g. "unused
packages" low-importance housekeeping.
The overall workflow for requests can be improved for sure, that is out
of the question.
Orphan requests should also be enhanced, e.g. if lingering for weeks and months
without any response by maintainer, any AUR comment by maintainer, and any
commit by maintainer, then the should be auto-accepted.
This sounds like a valuable improvement. I thought the AURWeb had some
scripts which ran every 6 months to auto orphan old packages but I can't
find anything for it.
AUR rules that are vague could also be clarified further, to reduce ambiguity
in evaluating the legitimacy of requests.
Agreed. I for one find it valuable to also include ARM/RISC-V packages
in the AUR. If we ever want to expand into support ARM that would be
very valuable.
There are use cases that are not addressed at all by current guidelines. E.g.,
AppImage based binary packages and their naming, and also naming Electron based
packages that do or do not bundle their own copy of the electron runtime.
In case some AUR packages are kept for extra-AUR applications that are not
submitted, the proper solution is to create helper metapackages that hold the
needed dependencies, so that the extra-AUR applications can easily be installed
and made to work.
Otherwise "dangling" libraries with no other packages to use them with just
look utterly useless on AUR.
AUR guidelines should set this requirement, spelling out explicitly that
without legitimate consumers on AUR, many-years-old libraries without any
downstream dependents, especially if they are also lacking any or at least a
responsive maintainer, are fair game for deletion.
Automated checking systems could also help, though deleting packages based
solely on bots' evaluation could also be problematic. (Although some obvious
filters could be used for auto-deletion with maybe a deadline, e.g. for using
sudo inside the PKGBUILD.)
Uhm, what I hinted at, is maybe a one time script to remove all packages
which are not functioning because of a missing source and aren't
touched. This can be done by us the AUR maintainers rather efficiently
and hopefully foolproof by parsing SRCINFO files.
For example:
https://aur.archlinux.org/cgit/aur.git/tree/.SRCINFO?h=vim-autocomplpop&id=7484a010ea0b03450695db7976de8631769e6d59#n10
What doesn't work well is filling thousands of requests with which we
can't keep up with. It helps a ton if you get the AUR Staff behind your
cleanup, then we can help and implement things quickly via automation.
Nevertheless, a human like myself is actually a valuable evaluator when it
comes to submissions, despite the hostile and demeaning accusations and
classification that I have seen levied against me.
I think also that fair treatment is a necessity when one is accused and framed,
and such attacks should be called out rather than being tolerated or outright
condoned. If AUR staff gives in to such, that would just alienate good-faith
members like me.
I don't read the email of 7Ji as an attack or framing. They raise
concerns about the amount of requests you fill. If I look at the
requests page now I see 4 within 30 seconds which can give the
impression that it is automated, note that they said in their email
"script-like" which does not imply it is scripted.
Greetings,
Jelle
