[aur-general] Question about AUR submission guidelines rule #1

[Chris Billington]

My AUR packages (pkgbase: linux-versioned-bin and linux-lts-versioned-bin)
are identical to the repo kernels, but with renamed packages/files so as to
allow multiple versions to be installed simultaneously without conflict.
They are an experiment in resolving bug 16702 (
https://bugs.archlinux.org/task/16702), and I think should be allowed to
exist, though they would seem to fall afoul of the rules too! There are no
patches to the upstream for example - merely packaging differences.

Another AUR package of mine, mercurial-python3 is the same as the official
repos except built with Python 3 instead of Python 2. Again this isn't a
patch, it's a change in the build process. (This package is required for
other AUR packages - specifically tortoisehg, but will be superseded by the
official repos once [community]/mercurial builds with Python 3 which I
expect to occur soon - I think it was held back due to a specific bug).

It seems like the rules are trying to say what *is* allowed instead of what
isn't, when the latter might be clearer. It seems that what is intended is
something like:

"AUR packages may not comprise unmodified official upstream releases of
packages in the official repositories, regardless of version. Packages
whose source or build are modified compared to the official repositories
are allowed, but must reflect those modifications in the package name.
<examples>"

There likely need to be further exceptions even to that though - Qt4, gcc7,
Python2 (the latter still in the official repos but sometime soon will be
AUR only) - these are unmodified different versions of packages available
in the official repositories. But they are the kind of "different version"
that have crossed the threshold of meriting being separate packages. This
should be allowed too (otherwise the Qt4 package would be violating the
rules already). Other older versions of Python such as 3.5, 3.6, 3.7 are
also available in the AUR. Are they in violation of the intention behind
the rules, or should exceptions be carved out for them as well? If so,
maybe the criterion for an exception should be if the package is : a) an
older release than in the repos and b) does not conflict with the package
in the official repos. My impression of the rule is that it is intended to
focus efforts on improving repository packages, rather than having a
"mutiny" of sorts and people moving to an AUR package just because a
repository package is out of date. But *older* packages don't exacerbate
that issue, so perhaps they should be allowed to.

After that the rule would be something like:

"AUR packages may not comprise unmodified official upstream releases of
packages in the repositories, regardless of version. Packages whose source
or build are modified compared to the official repositories are allowed,
but must reflect those modifications in the package name. An AUR package
for an *older* upstream release of a package than that in the repositories
is allowed, provided it does not conflict with the corresponding package in
the official repositories. <examples>"

Perhaps I've misunderstood the intent behind the rule, but it seems like it
would need to be much more limited than at present, unless one bites the
bullet and says many of these AUR packages should be removed.

-Chris


On Thu, Feb 27, 2020 at 10:43 AM Lone_Wolf <lone_wolf at klaas-de-kat.nl>
wrote:

> Hi,
>
>
> Scimmia pointed me to [1] in answer of  a request by me on forum. I
> re-read the page and realised the exception to the first rule leaves
> some things open.
>
> text quoted from wiki for reference :
>
>   * The submitted PKGBUILDs must not build applications *already in any*
>     of the *official* binary *repositories* under any circumstances.
>     Check the official package database
>     <https://www.archlinux.org/packages/> 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
>     <https://bugs.archlinux.org/>.
>
>     *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.
>
>
> The package types listed below are in AUR and appear to be allowed but
> are not mentioned in the exception .
>
>
>         - packages that *remove *features.
>
> example : mesa-noglvnd[2] disables glvnd support but is otherwise the
> same as extra/mesa of the same upstream version .
>
> Maybe change the wording to clarify this ?
>
>
>         - VCS packages building trunk master or specific branches
>
> example : gcc-git [3]
>
> The PKGBUILD is very similar to repo version, but it does build trunk
> master.
>
> Are they considered to have 'patches' or should they be mentioned
> specifically ?
>
>
>         - VCS packages building a specific commit or revision
>
> (Sorry, can't find an example atm.)
>
> Usually these are considered 'stable' versions. Are they seen as
> packages having patches or should they have their own rule ?
>
> Suppose we have  2 packages of this type :
>
> A builds a commit that matches exactly with latest released version, B
> builds some commit without a tag or label..
>
> In my opinion A violates rule#1, but I'm unsure about B.
>
> How do we make the difference clear ?
>
>
>         - Older versions of repo packages
>
> There are plenty of older versions of repo packages in AUR . Just search
> for gcc or llvm.
>
> I don't see anything in the exception that applies to these packages.
>
>
> Lone_Wolf
>
>
> [1] https://wiki.archlinux.org/index.php/AUR_submission_guidelines
>
> [2] https://aur.archlinux.org/packages/mesa-noglvnd
>
> [3] https://aur.archlinux.org/packages/gcc-git/
>
>