[aur-general] some questions mainly about deletion...
ainola at archlinux.org
Tue Nov 30 19:12:50 UTC 2021
On 2021-11-30 15:55, zoorat via aur-general wrote:
>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.
>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:
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:
You also should have a dashboard at aur.archlinux.org that shows your
>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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the aur-general