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

Thu Feb 27 16:26:05 UTC 2020

On February 27, 2020 11:19:20 AM EST, Chris Billington via aur-general <aur-general at archlinux.org> wrote:
> 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/
> >>
> >>

Edits to that page are restricted to wiki maintainers. Please make suggestions via its talk page.

--
Best,
Daniel <https://danielcapella.com>