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

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20200227/12406ba2/attachment.sig>