Packaging upstream binaries when we already have official releases

[Brett Cornwall]

Hey all,

I've been getting some mixed signals on whether or not we support 
packaging upstream binaries in the AUR when we already have packages in 
the official repository. The issue reached maximum farce with the 
removal of telegram-desktop-bin (PRQ 30701), which prompted a long chain 
on aur-general (message ID dcebfd89-d4fb-92aa-52f5-668113817884 at cock.li)

For some set dressing, 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.


My statement on that thread:

>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.

I was shortly rebuked by another TU, claiming that I should have 
inspected the package since it *obviously* is different because it was 
built without support for pipewire (unless I'm misunderstanding, I could 
not know that without comparing binaries).

This could spiral off into existential questions, like "couldn't they 
just have a PKGBUILD based off of the Arch telegram-desktop package with 
different compile-time options and have called it e.g. 
"telegram-no-pipewire" or the concept of combining all the various 
flavors of

The issues here are twofold:

1. Some TUs think that "built by upstream" is enough of a feature to 
warrant its own package while some don't.

2. Differences between official Arch packages and upstream-built 
binaries are pretty opaque.

My ultimate questions are:

Do we *definitively* allow -bin packages when we already have them in 
the official repos (i.e. is "built by upstream" enough of a feature to 
warrant the package's existence)?

     a. If so, can we reword the rules of submission to explicitly allow 
     such packages so we can avoid these conflicts?

         i. Where do we then draw the line between something like 
         telegram-desktop-bin where people use it for a specific feature 
         (in this case let's just say lack of pipewire support) and a 
         build-from-source package that builds with the appropriate 
         flags?

     b. If not, can we create an RFC and come to a definitive agreement 
     on whether or not we allow them so that we can avoid these conflicts?

Do we want to support other "official" packages, such as appimage, 
flatpak, docker, etc.? One could logically conclude that "built by 
upstream" being enough of a feature to be permitted submission could 
extend to all these various distribution methods. If -bin is allowed 
alongside our official packages, Where do we draw the line?


[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission
-------------- 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-dev/attachments/20211228/bc6d7958/attachment.sig>