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