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
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@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 branchesexample : 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 packagesThere 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
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 lone_wolf@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 branchesexample : 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 packagesThere 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
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 < 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 anycircumstances.
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 theofficial
package is out-of-date, flag it as such. If the officialpackage 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 theofficial
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 inorder
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 branchesexample : 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 packagesThere 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
Edits to that page are restricted to wiki maintainers. Please make suggestions via its talk page.
-- Best, Daniel https://danielcapella.com
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
aur-general@lists.archlinux.org