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
-- Eli Schwartz Bug Wrangler and Trusted User