[aur-general] Handling coincidental name collisions

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20190209/1b0d8cf8/attachment.sig>