hi, i have been CCed enough times, so i might give my opinion a bit. 2 years ago, when i was spamming deletion requests kinda like MarsSeed, i was asked to stop making deletion requests for packages with broken dependencies because, i was told that, some script would be developed to help to clean up AUR. right after that, my laptop died, and ... at that time, i wrote a script that downloads `packages-meta-ext-v1.json.gz` and checks for packages with broken dependencies. then i would manually review them and file for deletion. but after coming back when i ran the script again, i saw packages with my comments saying they were broken and needed to be fixed... so i guess the scripts are still in development... i would love to help if that's the case. i do understand that spamming arch-request is not the best way to go about it, so i think it will be cool to have an official place for those who wanna clean up AUR to collaborate and build up a list(IRC is the best place for making a list), then file a bulk deletion request. and i think we need much more detailed documentation about where to draw the line about what is allowed in AUR. seems like reality is quite complicated :) e.g. some of my questions Q: Should the library package be deleted if there is no dependency ?? - some people say they might be used in later packages but then how long or ever that pkg be there ?? Q: when is it ok to have ARM-only packages ?? - i do agree with @felixonmars's comment and i sure don't wanna discourage people, what should be done ?? and my biggest question after the last few days of mail exchange Q: is it ok for people like me and MarsSeed to try to find broken/out-of-line packages and file deletion req ?? is it ok to actively seek out and try to clean up ?? i do understand this question's answer might be "depends". but at least i would like to know in detail what's the philosophy about/of AUR. there seem to be many opinions and confusion. so, i will wait for a concrete answer before i test for broken packages. don't forget those are just **opinions** mate and i hope i haven't made anyone disappointed. also sorry for my bad english, if anything confuses you mail me. have a nice day. p.s. i wanna translate archwiki to bangal. if you have any advice, that would be awesome. On 11/15/23 21:39, Jelle van der Waa wrote:
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:
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
-- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat