On February 27, 2020 11:19:20 AM EST, Chris Billington via aur-general <aur-general@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 < > chrisjbilling...@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_w...@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>