[aur-general] Clarification for Deletion request #30701

[Brett Cornwall]

On 2021-12-28 15:35, alad wrote:
>> And how am I supposed to have known that?
>>
>By looking at how the packages differ before simply accepting the request?

I'm not going to compare binaries for each -bin request in the hopes 
that there's some difference that makes it worthwhile to keep. It's the 
packager's job to describe what the package's use is; That's what the 
description field is for. telegram-desktop-bin's *only* message was that 
it was built by upstream and nothing more.

Again, if someone wants that package without the deps, 
telegram-no-pipewire or telegram-minimal is a better option.

>> It sounds like someone could merely make e.g. telegram-no-pipewire
>> package that builds with the respective flags. Is "it's built by
>> upstream" reason enough to break the rules of submission quoted above?
>>
>> More broadly, are we to allow all upstream binaries to be packaged? If
>> so, can we designate a different suffix than -bin so that I don't draw
>> ire when I dare accept the removal request of a package with no
>> difference in denotation than the in-repo packages? Or can we get in
>> writing the acceptance of AUR packages of "upstream" releases alongside
>> our own official packages?
>>
>> As it stands, I am getting feedback both ways: One side is in agreement
>> with me that -bin packages needn't exist and that no, "but it's
>> upstream" is not a valid reason. But the other side screams loudly when
>> *their* favorite upstream package is removed in accordance to that (and
>> never any other time).
>
>I am general disagreement of people widely removing packages from the AUR, merely because it is an upstream build (built on different machines, with different purposes). Even popular packages like firefox-bin have been deleted because of this.
>
>If a different suffix will avoid these kind of knee-jerk responses, I'm all for it.

Feel free to post an RFC. In the meantime, I'll continue to follow the 
rules that have been established.
-------------- 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/20211228/80d93610/attachment-0001.sig>