[aur-general] Clarification for Deletion request #30701
Doug Newgard
dnewgard at outlook.com
Tue Dec 28 19:17:51 UTC 2021
On Tue, 28 Dec 2021 10:34:58 -0800
Brett Cornwall via aur-general <aur-general at 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 at 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.
> I don't care about what we do, so long as it's consistent with our
> rules. Saying "it's always been this way" is an appeal to tradition and
> is not helpful as an argument.
>
> So yes, an RFC/change in how our *rules* say we should behave would be
> the correct way forward instead of having three different
> interpretations of what we currently have.
>
> [1]
> https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission
More information about the aur-general
mailing list