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