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

Thu Feb 27 16:19:20 UTC 2020

Apologies, Lone_Wolf already mentioned the case of older versions of
packages.

I suppose my only additions then are that "modified build process" should
be allowed, and that maybe the criterion for older versions to be allowed
should be that they do not conflict with the corresponding newer package in
the repo.

-Chris

On Thu, Feb 27, 2020 at 11:12 AM Chris Billington <
chrisjbillington at gmail.com> wrote:

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