On 2021-11-30 15:55, zoorat via aur-general wrote:
Hi everyone, I have been hunting for broken packages and filing deletion requests against them for a while now...
Thanks for all of your help on that!
1. to TU's, how do you guys are checking if a package should be deleted or not ?? I want to know it to make the right call and not to spam...
https://wiki.archlinux.org/title/AUR_submission_guidelines is a good reference to start with, but ultimately you're going to get different answers from different people. IMO it ultimately boils down to "Is this package maintained/does it have a future that isn't rotting in the AUR?" and "is it useful to other people?".
I'm kinda asking for a list of scenarios with some comments... example list from my experience: "broken dependency and orphan" dead for sure.
Those are signs that they're ready for deletion. Low votes/popularity in addition would guarantee that it's ready to go.
"problem was reposted a long time ago and not fixed" dead.
If it's been a problem for a long time then nobody's cared enough to submit an orphan request to fix it so I'd say it's ready to die. If it's only been a few months and the package is somewhat popular then an orphan request is more appropriate.
"Flagged out-of-date" better giving this info while making the request.
Flag a package as OOD only if the package is out of date; It's not a general "this package is broken" button. :) For issues with a package, use the comments section.
"orphan but nothing broken" false request.
If it's low popularity or older, file for deletion - the AUR (attempts to) be a somewhat curated repository of *useful* packages and if a package is not popular *and* orphaned, it's not useful. If someone ever wants to revive it the repos are still there for resubmission. If it's a more popular package or it's only recently been orphaned, maybe give it some time before filing.
you can also tell me, what makes a package is good and healthy...
Again, this is subjective, but my own opinion is: 1. Package is kept up-to-date with upstream 2. Package does not depend on deprecated tech (gtk2, python2, etc.) 3. Maintainer actively responds to comments/issues It's entirely possible that a package is up-to-date with upstream but upstream hasn't changed since 2015 (i.e. the package is "finished"). From there, it's a judgement call: Do users find this package useful?
2. how to file deletion requests for split packages ?? tried to find out about it but google was unhelpful... when I file a deletion request, it is going to be a request for the base package like the vote. isn't it?? then if one of the base packages is broken and needed to be removed then what I should do then ?? file a request saying it's for only that package ?? or tell the maintainer to remove that package's code from the PKGBUILD ?? and what I should do if the package is orphan ??
Do you mean filing a deletion request for only one package out of multiple? If so, you can't! Requests are against the base package so you'd want to get in contact with the maintainer.
3. inactive maintainer is not fixed...
there is a lot of packages which is not orphan but the maintainer is not fixing the problem after reporting. saw this a lot when I was testing font packages... what should I do in this case ??
If it's a useful package you'd like to maintain or you think that the community would use, orphan request. If the package isn't popular/you think the community wouldn't really use it, submit a deletion request.
If it's a package not being dependent on others, can I file a deletion request after a certain time ?? how long should I wait ??
There's no set rule for this, but you can just think of it as "how much time would I as a maintainer appreciate before someone requests deletion of my packages?"
If the answer to the last question is "disown and maintain" and if I'm not interested in maintaining that package, how I should let other people know who might want to maintain ?? this aur-general mailing list ??
Again, if it's not a popular package, there's unlikely to be much supply of talent to maintain the package. It should be deleted. If someone wants that package they can always re-submit at a later time.
4. font source problem...
I tested 1104 font packages that start with 'ttf-' or 'otf-' (got the list on 2021-11-17) if their source works and checksum matches or not and also for broken dependency.
Font sources are weird. like for some, you need the browser to download (you know how mega.nz downloads), certificate error on curl/wget but not on firefox, file hash changes like fontspace.com, the URL is temporary, the original source is dead but you know there is a lot of mirrors.
it's pretty common... so can I ask maintainers to download from a mirror that is not in archwiki/Font_package_guidelines, or set up a github/lab mirror themselves and download from there ?? or should they make the package like "ttf-ms-win10" which lets the user know how to get the file to make this package ?? don't know if this kinda package is allowed...
We should be using upstream sources and not mirroring things ourselves. I'd work with upstream to have them distribute on a better platform that respects users a little more. If the AUR package's source isn't working, the maintainer should either fix it or the package should be deleted. Generally, PKGBUILDs should require no user interaction (i.e. absolutely no user prompts ever) but there is a reality in which some software cannot be downloaded via the PKGBUILD (like licensed junk that requires users to download from a server beforehand). For instance, Mathematica: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mathematica Again, it boils down to usefulness: Mathematica is a useful package that many people want to use. An obscure font submitted from some dumpy site that doesn't allow curl would not be a useful addition to the AUR. A very popular font like ttf-ms-win10 is a valuable addition to the AUR in spite of a hostile upstream.
5. how to get the exact number of requests I had to make and how many of them got accepted... do you know any easy to get that info?? or do I have to somehow parse and count mbox files from aur-requests archives?
AFAIK aur-requests archives or your own inbox is the best way: https://lists.archlinux.org/pipermail/aur-requests/ You also should have a dashboard at aur.archlinux.org that shows your recent requests.
Don't know if I'm nitpicking... Tell me, if I'm doing something wrong or not.
You're doing great. Thanks for your help on cleanup! Just remember that there's over 70 thousand packages and only 60 TUs, so there's a *lot* of packages that are abandoned/inappropriate. Chances are, if you're feeling like a package doesn't belong, you're probably right. ;) If you do something wrong, we should be able to provide good reasons why in a rejection. So don't sweat if it gets rejected. Hope this helps.