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

newer
[aur-general] Anydesk 404 not found

Lone_Wolf

27 Feb 2020 27 Feb '20

3:36 p.m.

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/

Show replies by date

Chris Billington

27 Feb 27 Feb

4:12 p.m.

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

Chris Billington

4:19 p.m.

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

Daniel M. Capella

4:26 p.m.

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

Eli Schwartz

4:36 p.m.

On 2/27/20 10:36 AM, Lone_Wolf wrote:

...

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

It has the feature of avoiding glvnd for people who dislike glvnd?

...

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

Well, those certainly do have patches, and the suffix -git indicates what form those patches take, I suppose. The wording could possibly be tweaked to make this clearer, but I would consider it already covered.

...

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

Packages that build from an arbitrary commit are no different from packages that build from a stable tag -- they must have a really good excuse for why the official repository version is insufficient.

...

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

This is the only thing which I believe contains true ambiguity in the current guidelines. The counterpoint is that we do package things like qt4, gtk2, python2, ruby2.6, gcc8, llvm7, electron{2,4,5,6} as dependencies for other software, in the official repos. On the other hand, we generally do not want such packages anyway. Unless they are dependencies for some other package and thus needed. So I really do not want to imply carte blanche to upload old versions of random packages to the AUR either. One solution would be to leave it as uncovered, thereby reserving the right to delete them at any time, with the unspoken acknowledgement that we, the TUs, will not actually delete such AUR packages unless we would likewise delete them from the official repositories for the same reasons.

...

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/

-- Eli Schwartz Bug Wrangler and Trusted User

1520

Age (days ago)

1520

Last active (days ago)

List overview

Download

4 comments

4 participants

participants (4)

Chris Billington
Daniel M. Capella
Eli Schwartz
Lone_Wolf