On 2021-12-28 13:17, Doug Newgard via aur-general wrote:
On Tue, 28 Dec 2021 10:34:58 -0800 Brett Cornwall via aur-general <aur-general@lists.archlinux.org> wrote:
On 2021-12-28 12:08, Doug Newgard via aur-general wrote:
On Tue, 28 Dec 2021 09:21:01 -0800 Brett Cornwall via aur-general <aur-general@lists.archlinux.org> wrote:
Feel free to post an RFC. In the meantime, I'll continue to follow the rules that have been established.
Established where? Upstream builds as -bin packages were fine in the AUR for years, it's only recently that a couple of TUs have decided to disallow it.
Established in the AUR submission guidelines [1], which has been quoted thrice now:
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.
The point of this section is to prevent people from uploading updated version of repo PKBGUILDs because they're impatient. That's why it specifically talks about that. You may interpret it differently, but that's not how it was meant or how it has been done in the past.
You'll also note that it gives exceptions for software that's build differently, different options/libs/etc. That would easily cover this case, as upstream will NOT be building it the same way as Arch.
Ah, cool, so we can have infinite different builds of software already released in the official repos because they're technically built for different distribution methods? -bin, -appimage-bin, -flatpak-bin, -guix-bin, -docker-bin? Should we just do away with deletion requests entirely except for the illegal/malicious packages? Condoning the AUR as a literal dumping ground of binary distributions is fine (I guess) so long as we're on the same page. Clearly, I'm not the only one interpreting this "incorrectly" as these are not infrequent requests. So while we may be wrong it behooves us to update the Wiki to *explicitly allow* these kinds of packages. "Someone affiliated with the project built this for us" is not a valid feature to be an exception in my (and a few other TUs') opinions. Let's RFC this.