[aur-general] Handling coincidental name collisions
Hi everyone, This is in regard to this thread on the forum: https://bbs.archlinux.org/viewtopic.php?id=244051 The packaged contained this project: https://github.com/Aniket-Pradhan/lsd To summarize the thread, an AUR package that had existed for a while was deleted when an unrelated package of the same name was moved to [community]. The reason given was that the AUR package was "not useful enough", either because it only had 2 votes or because the acting TU saw no personal use for it. For trivial packages, it would be good to at least clarify the reason for deletion in a little more detail. There are plenty of AUR packages that persist for years with 0 votes so a maintainer with 2 votes may be understandably confused by the terse statement "not useful enough". A little clarification can easily disperse that confusion and better guide the user through future contributions. However, "trivial" here usually means that someone uploaded a bash script to do something like open arandr and click on it with xdotool to save half a second, or baked some convoluted ls-cat-cat-grep-cat-sed-cat pipe into a 3-line script. The project involved here is not in the same category. It may not be practically "useful" for many users, but it does do something that is not trivial to replicated in a few lines of shell code. It's "usefulness" is subjective. In this case, the TU should have proposed renaming the package, given the maintainer some time to pick a new name and re-upload the package, and then merged the old one. Even a single vote from another user can be encouraging so the merge is worthwhile unless the maintainer states otherwise. Regards, Xyne
Am 09.02.2019 um 14:34 schrieb Xyne:
Hi everyone,
This is in regard to this thread on the forum: https://bbs.archlinux.org/viewtopic.php?id=244051
The packaged contained this project: https://github.com/Aniket-Pradhan/lsd
To summarize the thread, an AUR package that had existed for a while was deleted when an unrelated package of the same name was moved to [community]. The reason given was that the AUR package was "not useful enough", either because it only had 2 votes or because the acting TU saw no personal use for it.
For trivial packages, it would be good to at least clarify the reason for deletion in a little more detail. There are plenty of AUR packages that persist for years with 0 votes so a maintainer with 2 votes may be understandably confused by the terse statement "not useful enough". A little clarification can easily disperse that confusion and better guide the user through future contributions.
However, "trivial" here usually means that someone uploaded a bash script to do something like open arandr and click on it with xdotool to save half a second, or baked some convoluted ls-cat-cat-grep-cat-sed-cat pipe into a 3-line script. The project involved here is not in the same category. It may not be practically "useful" for many users, but it does do something that is not trivial to replicated in a few lines of shell code. It's "usefulness" is subjective.
The "original" lsf looks like a joke/troll package to me, rather than "trivial". I'd have deleted it even without community duplicate. Alad
In this case, the TU should have proposed renaming the package, given the maintainer some time to pick a new name and re-upload the package, and then merged the old one. Even a single vote from another user can be encouraging so the merge is worthwhile unless the maintainer states otherwise.
Regards, Xyne
On 2019-02-09 14:36 +0100 alad via aur-general wrote:
The "original" lsf looks like a joke/troll package to me, rather than "trivial". I'd have deleted it even without community duplicate.
Alad
To me it just looks like the package of someone discovering bash programming with ANSI escape codes and wanting to share. The fact that it's on github with a README.md and a preview is an argument against it being a joke/troll. Please explain why you feel differently and why such packages should be removed from the AUR. What exactly are your criteria for allowing a package to remain? The discussion is important because we need to have a general consensus on deletion criteria. Rogue TUs can't be allowed to roam the AUR deleting whatever they personally don't find useful on a given day. Xyne
On 2019-02-09 14:49, Xyne wrote:
On 2019-02-09 14:36 +0100 alad via aur-general wrote:
The "original" lsf looks like a joke/troll package to me, rather than "trivial". I'd have deleted it even without community duplicate.
Alad
To me it just looks like the package of someone discovering bash programming with ANSI escape codes and wanting to share. The fact that it's on github with a README.md and a preview is an argument against it being a joke/troll.
Agreed. This is pretty clearly not a troll package. It's an easy-to-run script that could easily be featured in one of those 'Top 5 things the Linux terminal can do' articles.
The discussion is important because we need to have a general consensus on deletion criteria. Rogue TUs can't be allowed to roam the AUR deleting whatever they personally don't find useful on a given day.
"All art is quite useless." -Oscar Wilde I'd propose that malicious/spam packages get deleted in this manner, and nothing else. We can't police what people want to do with their installation. Scripts like this may be trivial but they're bound to give enough people joy. Occasionally I zen out to asciiquarium (admittedly a much more involved program but no more useful than lsd) every now and then. The point is, it was a legitimate program and should be welcomed in the AUR like any other (with the naming conflicts resolved).
On Sat, Feb 09, 2019 at 02:49:33PM +0100, Xyne wrote:
The discussion is important because we need to have a general consensus on deletion criteria. Rogue TUs can't be allowed to roam the AUR deleting whatever they personally don't find useful on a given day.
`Make sure the package you want to upload is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.` https://wiki.archlinux.org/index.php/Arch_User_Repository#Rules_of_submissio... 4 stars on github and...0 votes on the AUR (?) would probably constitute a very specialized package. This was handled with a deletion request and not blindly deleted, so I don't see the fuzz here personally. -- Morten Linderud PGP: 9C02FF419FECBE16
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, February 9, 2019 1:49 PM, Xyne
On 2019-02-09 14:36 +0100 alad via aur-general wrote:
The "original" lsf looks like a joke/troll package to me, rather than "trivial". I'd have deleted it even without community duplicate. Alad
To me it just looks like the package of someone discovering bash programming with ANSI escape codes and wanting to share. The fact that it's on github with a README.md and a preview is an argument against it being a joke/troll.
For me, your program is not far from discovering bash programming. The fact that it has github page and README.md tells nothing. Having those does not mean such software can be uploaded to AUR. Try to look objectively. You have discussed this issue in the mailing list and at forum and it seems nobody finds your package useful.
Am 09.02.2019 um 14:49 schrieb Xyne:
On 2019-02-09 14:36 +0100 alad via aur-general wrote:
The "original" lsf looks like a joke/troll package to me, rather than "trivial". I'd have deleted it even without community duplicate.
Alad To me it just looks like the package of someone discovering bash programming with ANSI escape codes and wanting to share. The fact that it's on github with a README.md and a preview is an argument against it being a joke/troll.
Please explain why you feel differently and why such packages should be removed from the AUR. What exactly are your criteria for allowing a package to remain?
The discussion is important because we need to have a general consensus on deletion criteria. Rogue TUs can't be allowed to roam the AUR deleting whatever they personally don't find useful on a given day.
Xyne
For the record: I did not delete, request for deletion, nor upload apackage with same name to community. When I look at the removed package however, I see a bash script which takes up all available resources to display an animation which may induce severe health issues to some users, i.e. induce epileptic attacks. When the package furthermore has no other defined purpose - as Morten pointed out, this is clearly something overly specialized - *and* the deletion was handled according to procedure (with a deletion request, see below), then I don't see the issue. On the deletion request: it can be seen at [1]. It likely should have been accepted by a different TU than the requester, as well as given more time than 11 minutes before acception. Now if this were some systemic issue, rather than the occasional mistake any of us might make, then I could see why we'd have this discussion. In my experience, it is the occasional mistake. [1] https://lists.archlinux.org/pipermail/aur-requests/2019-February/029689.html Alad
Maksim Fomin via aur-general wrote:
For me, your program is not far from discovering bash programming. The fact that it has github page and README.md tells nothing. Having those does not mean such software can be uploaded to AUR.
Try to look objectively. You have discussed this issue in the mailing list and at forum and it seems nobody finds your package useful.
It's not my package or my code.
alad via aur-general wrote:
When I look at the removed package however, I see a bash script which takes up all available resources to display an animation which may induce severe health issues to some users, i.e. induce epileptic attacks.
I somehow doubt that epilepsy was at any point a consideration in the deletion :P
When the package furthermore has no other defined purpose - as Morten pointed out, this is clearly something overly specialized - *and* the deletion was handled according to procedure (with a deletion request, see below), then I don't see the issue.
The deletion request itself gives an invalid reason: it was not "supersed"(ed) by the unrelated package in community. Also, just following the procedure (report, delete) doesn't make any difference to the validity of the deletion. Reports are just for regular users to bring the package to the attention of a TU. The issue is that there are plenty of packages in the AUR that most people would never find useful, but that's never been a criterion for deletion in itself. The issue here is that seemingly arbitrary discretion was applied without any real reasoning given.
On the deletion request: it can be seen at [1]. It likely should have been accepted by a different TU than the requester, as well as given more time than 11 minutes before acception. Now if this were some systemic issue, rather than the occasional mistake any of us might make, then I could see why we'd have this discussion. In my experience, it is the occasional mistake.
I agree that it was likely just an inattentive mistake while working through the requests. Nevertheless, it led to a user bringing it up on the forum so I felt it necessary to address it here. It really isn't a big deal, but it would be better to avoid repeating in the future if possible. As the number of TUs continues to grow, we have to make sure that we agree on how policy is meant to be implemented, otherwise it's very unfair to some users.
[1] https://lists.archlinux.org/pipermail/aur-requests/2019-February/029689.html
Alad
On 2/9/19 2:35 PM, Xyne wrote:
When the package furthermore has no other defined purpose - as Morten pointed out, this is clearly something overly specialized - *and* the deletion was handled according to procedure (with a deletion request, see below), then I don't see the issue.
The deletion request itself gives an invalid reason: it was not "supersed"(ed) by the unrelated package in community. Also, just following the procedure (report, delete) doesn't make any difference to the validity of the deletion. Reports are just for regular users to bring the package to the attention of a TU.
I agree -- there is no "procedure" for deleting packages at the moment, only a partially shared sense of politeness.
The issue is that there are plenty of packages in the AUR that most people would never find useful, but that's never been a criterion for deletion in itself. The issue here is that seemingly arbitrary discretion was applied without any real reasoning given.
On the deletion request: it can be seen at [1]. It likely should have been accepted by a different TU than the requester, as well as given more time than 11 minutes before acception. Now if this were some systemic issue, rather than the occasional mistake any of us might make, then I could see why we'd have this discussion. In my experience, it is the occasional mistake.
I agree that it was likely just an inattentive mistake while working through the requests. Nevertheless, it led to a user bringing it up on the forum so I felt it necessary to address it here. It really isn't a big deal, but it would be better to avoid repeating in the future if possible.
It was hardly an inattentive mistake while working through requests when the same TU who submitted the request after adding a totally different package to community under the same name, also clicked the delete button 11 minutes later. I do not say it was right or wrong, but it was unquestionably highly premeditated. The mistake here, perhaps, is that there is no policy for what, precisely, constitutes the polite thing to do to someone else's package.
As the number of TUs continues to grow, we have to make sure that we agree on how policy is meant to be implemented, otherwise it's very unfair to some users.
Unsure what this has to do with the number of TUs. Is a small, select group of 15 TUs less vulnerable to unfair behavior than a large group of 70? ... Anyway, Xyne, you make an excellent point, which some people seem to be getting confused about, so I'd like to remind everyone of a very important fact: this is not about whether the package was useful or not, and it is not about whether the package deserved the name or not. It is about whether packages should be YOLO deleted from the AUR for absolutely, positively no reason whatsoever. It is standard operating procedure to delete a package when it is moved to community, because it does not need to be in both places at once -- but this was not moved, it is a different piece of software, so this logic is automatically invalid. For what it's worth, as I pointed out on the forum, both the community software and the AUR software are pointless, as judged by me in my completely unbiased and neutral position as the ultimate arbiter of good taste in software. But it is still software. It is software that is objectively useful to more than one person, and guess what? It's not any less useful than https://www.archlinux.org/packages/community/any/doge/ which is a community package which is also pretty pointless. Apparently it's popular though. (What would be a package that is not useful to more than one person? Well, I've deleted packages before which, I kid you not :/ installed the data files for one weird person's website. See e.g. "legal-notes".) ... It is true: the AUR does not have namespacing. Github automatically namespaces things by username, package managers typically do not (although Gentoo does: you can have sys-apps/pacman and games-arcade/pacman). We certainly don't have a utility to handle conflicting binaries in /usr/bin (like Debian update-alternatives). The AUR will automatically blacklist the package as soon as it is detected in community, and the maintainer must re-upload under a better, namespaced name (they have done so) if they ever want to update it. Okay-- we have provisions for this, and we should use it. Especially, if the package had votes and/or comments, we should give the maintainer a chance to preserve those. -- Eli Schwartz Bug Wrangler and Trusted User
Am 09.02.2019 um 20:35 schrieb Xyne:
alad via aur-general wrote:
When I look at the removed package however, I see a bash script which takes up all available resources to display an animation which may induce severe health issues to some users, i.e. induce epileptic attacks. I somehow doubt that epilepsy was at any point a consideration in the deletion :P
When the package furthermore has no other defined purpose - as Morten pointed out, this is clearly something overly specialized - *and* the deletion was handled according to procedure (with a deletion request, see below), then I don't see the issue. The deletion request itself gives an invalid reason: it was not "supersed"(ed) by the unrelated package in community. Also, just following the procedure (report, delete) doesn't make any difference to the validity of the deletion. Reports are just for regular users to bring the package to the attention of a TU.
Point taken, though it's always better when there's a report available than not. That way anyone can later look up the reason of deletion, instead of relying on information from whoever happened to be subscribed to the relevant package.
The issue is that there are plenty of packages in the AUR that most people would never find useful, but that's never been a criterion for deletion in itself. The issue here is that seemingly arbitrary discretion was applied without any real reasoning given.
I admit that, at least for my handling of user requests for package deletions, there's a *lot* of implicit criteria whether to accept them or not, including at what point in time to do so. It would probably be some undertaking to formalize these, in the bylaws or wherever else. A first step could be to check and expand the wiki criteria where needed. [2] [3] [2] https://wiki.archlinux.org/index.php/Arch_User_Repository#Rules_of_submissio... [3] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines
On the deletion request: it can be seen at [1]. It likely should have been accepted by a different TU than the requester, as well as given more time than 11 minutes before acception. Now if this were some systemic issue, rather than the occasional mistake any of us might make, then I could see why we'd have this discussion. In my experience, it is the occasional mistake. I agree that it was likely just an inattentive mistake while working through the requests. Nevertheless, it led to a user bringing it up on the forum so I felt it necessary to address it here. It really isn't a big deal, but it would be better to avoid repeating in the future if possible.
As the number of TUs continues to grow, we have to make sure that we agree on how policy is meant to be implemented, otherwise it's very unfair to some users.
[1] https://lists.archlinux.org/pipermail/aur-requests/2019-February/029689.html
Alad
On Feb 09 2019 20:36:16 -0500, Eli Schwartz via aur-general wrote:
On 2/9/19 2:35 PM, Xyne wrote:
When the package furthermore has no other defined purpose - as Morten pointed out, this is clearly something overly specialized - *and* the deletion was handled according to procedure (with a deletion request, see below), then I don't see the issue.
The deletion request itself gives an invalid reason: it was not "supersed"(ed) by the unrelated package in community. Also, just following the procedure (report, delete) doesn't make any difference to the validity of the deletion. Reports are just for regular users to bring the package to the attention of a TU.
I agree -- there is no "procedure" for deleting packages at the moment, only a partially shared sense of politeness.
On the deletion request: it can be seen at [1]. It likely should have been accepted by a different TU than the requester, as well as given more time than 11 minutes before acception. Now if this were some systemic issue, rather than the occasional mistake any of us might make, then I could see why we'd have this discussion. In my experience, it is the occasional mistake.
I agree that it was likely just an inattentive mistake while working through the requests. Nevertheless, it led to a user bringing it up on the forum so I felt it necessary to address it here. It really isn't a big deal, but it would be better to avoid repeating in the future if possible.
It was hardly an inattentive mistake while working through requests when the same TU who submitted the request after adding a totally different package to community under the same name, also clicked the delete button 11 minutes later.
I am mostly a "reader" in this list, but I though I'll contribute my two cents: maybe the (currently missing) procedure for deleting packages should stipulate that the same TU cannot submit deletion request and then act on it. Can this be enforced in the software? Assuming ordinary users cannot accept delete requests, the only change then should be to check if TU that is trying to accept the delete request is not the same TU that submitted the request in the first place. Cheers, Misha -- Vanush "Misha" Paturyan Computer Science Department Maynooth University Maynooth
participants (7)
-
alad
-
Brett Cornwall
-
Eli Schwartz
-
Maksim Fomin
-
Morten Linderud
-
Vanush Misha Paturyan
-
Xyne