[aur-general] Clarification for Deletion request #30701

[Brett Cornwall]

On 2021-12-27 23:26, alad via aur-general wrote:
>On Fri, 17 Dec 2021 07:01:08 -0800
>Brett Cornwall via aur-general <aur-general at lists.archlinux.org> wrote:
>
>> On 2021-12-17 09:54, Filipe Laíns via aur-general wrote:
>> >On Fri, 2021-12-17 at 00:17 +0100, Justin Kromlinger via aur-general wrote:
>> >> On Fri, 17 Dec 2021 01:05:19 +0200
>> >> silentnoodle via aur-general <aur-general at lists.archlinux.org> wrote:
>> >>
>> >> > hey all,
>> >> >
>> >> > Today a package i co maintain (telegram-desktop-bin) was deleted because
>> >> > "Package exists in official community repo", but since we used prebuilt
>> >> > binary as source I did not think that would have applied.
>> >> >
>> >> > So guess I'd just like a word on what the first point in the rules of
>> >> > submission means:
>> >> > https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission
>> >> >
>> >> > Cheers, Ben a.k.a silentnoodle
>> >>
>> >> So basically:
>> >> * telegram-desktop in community is git release 3.3.0 build by Arch Maintainers
>> >> * telegram-desktop-bin in AUR is git release 3.3.0 build by upstream
>> >>
>> >> For the end user, those two are basically the same package. Therefore the AUR
>> >> package is a
>> >> duplicate.
>> >>
>> >
>> >No, they aren't. I haven't looked into the request but if this is indeed the
>> >case, the package was incorrectly deleted.
>>
>>  From the rules of submission [1]:
>>
>> > The submitted PKGBUILDs must not build applications already in any of
>> > the official binary repositories under any circumstances. Check the
>> > official package database for the package. If any version of it exists,
>> > do not submit the package. If the official package is out-of-date, flag
>> > it as such. If the official package is broken or is lacking a feature,
>> > then please file a bug report.
>>
>> > Exception to this strict rule may only be packages having extra
>> > features enabled and/or patches in comparison to the official ones. In
>> > such an occasion the pkgname should be different to express that
>> > difference. For example, a package for GNU screen containing the
>> > sidebar patch could be named screen-sidebar. Additionally the
>> > provides=('screen') array should be used in order to avoid conflicts
>> > with the official package.
>>
>> Submitting a package that is only different from the technicality that
>> someone else built it is not enough to warrant its own package. If
>> there's an issue with the telegram package in the repos, users should
>> submit a bug report.
>>
>> As it stands, there was nothing notated in the package to suggest that
>> it was anything but an upstream binary, so that was why I deleted it.
>>
>> [1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission
>
>The upstream build is vastly different from the repos. Besides lacking bugs in the downstream version, it only has a fraction of the dependencies (i.e. no pipewire). As such I see no valid reason for the deletion.

And how am I supposed to have known that?

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).
-------------- 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/20211227/2cf1fde3/attachment.sig>