[aur-general] some questions mainly about deletion...

Brett Cornwall ainola at archlinux.org
Tue Nov 30 19:12:50 UTC 2021

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.
>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 
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20211130/36fe3887/attachment.sig>

More information about the aur-general mailing list