On 03/08/2017 04:06 PM, Ralf Mardorf wrote:

On Wed, 8 Mar 2017 18:00:52 -0300, Rafael Fontenelle wrote:

...

2017-03-08 17:53 GMT-03:00 Ralf Mardorf <ralf.mardorf@alice-dsl.net>:

...

Hi,

my understanding is, that if possible, it should look like this

1.2.r3.gabcdef7

and not alternatively

1.2_r3_gabcdef7

or

1.2_3_gabcdef7

A maintainer disagrees:

"The pkgver extracts on the wiki are not there as strict rules that you need to comply with, but simply as examples that produce good, incrementing pkgvers."

It's not important what AUR package I'm talking about, I just want to ensure that I'm not mistaken.

Regards, Ralf

Just add info to this thread, I don't know about "_" as separator, but some packages in official repositories use "+". e.g. gedit 3.22.0+4+g2c70ccb86-1

Then I'm seemingly mistaken. IMO it's odd, if there are many variations. It has a Debian/Ubuntu appeal, if packages have a different version/release formatting ;).

The fact that some repo packages go against established AUR packages (when they formulate the pkgver for a non-release upload) is, as you say, very odd and foments confusion. I *really* wish they (Devs/TUs) wouldn't do that... unfortunately there is no actual rule for or against it, for the simple reason that the only hard rules are against actual malware and things like that. No one is going to delete an AUR package (much less a repo package :p) for a confusingly nonstandard pkgver, we don't even delete packages that are *far* worse. In other words, maintainers of any stripe are absolute dictators over their package, as long as they don't commit offenses against the AUR package-hosting service itself, which would be grounds for deleting the package, and they keep their package up to date with upstream releases, which failure to do so is grounds for package orphaning. You (rhet.) can (and often do) highly disapprove of their choices, but at the end of the day, they cannot be *forced* to do anything. ... Nevertheless, none of that is an excuse to make things even worse, the _______ Package Guidelines are there *not* as "good advice" but as "good advice to make things both well-formed AND ORDERLY" (as the literal expression of an ideal form) and you can quote me on that if you like. :) -- Eli Schwartz

On 03/08/2017 07:37 PM, Ivy Foster wrote:

Of course, you also can't be forced to install a packaging whose versioning or build options you dislike. PKGBUILDs are trivial to edit to taste.

I recognize that the AUR ML is a slightly heretical place to suggest this, but...the AUR is not the end-all-be-all of packaging scripts. If you don't like what you see there, write your own or edit an existing one. It'll take you under five minutes if you start from scratch.

In short, if you don't like what you see on the AUR and it's not actually harmful, ignore it. You'll be happier you did.

Thank you for the advice. This is, in fact, what I already do (if it affects the built package in any way). :) But ideally, we could edit PKGBUILDs to taste *in addition to* providing general advice about commonly-agreed tastes, or even specific advice. It isn't an either-or kind of thing, I am multi-talented that way. :) :) -- Eli Schwartz

On Thu, 9 Mar 2017 02:01:47 +0100, Christian Rebischke wrote:

On Wed, Mar 08, 2017 at 05:12:19PM -0500, Eli Schwartz wrote:

...

No one is going to delete an AUR package (much less a repo package :p) for a confusingly nonstandard pkgver, we don't even delete packages that are *far* worse.

There are reasons why AUR is also called 'unsupported'. If the people would only push nice and clean AUR packages into the AUR, I guess the AUR would be nearly empty.

And I neither want to force a maintainer to do something, nor that a package gets deleted, but a maintainer, as well as a user might want to learn from mistakes. On Wed, 8 Mar 2017 19:52:05 -0500, Eli Schwartz via aur-general wrote:

...

In short, if you don't like what you see on the AUR and it's not actually harmful, ignore it. You'll be happier you did.

Thank you for the advice. This is, in fact, what I already do (if it affects the built package in any way). :)

And I do it, too. Btw. I didn't edit this particular unnamed PKGBUILD, since I can live with "_" instead of ".". I'm used to something similar from Debian and Ubuntu, where at least package releases are "very colourful". In my experiences upstream usually uses "1.2-3-gabcdef7", which conflicts a little bit with the "-" used for the Arch package release. Since the commits are part of the package version "1.2.r3.gabcdef7" seems to be a good compromise. I'm fine with anything else, just would prefer if all packages share the same formatting. "." as well as "_" and "+" are ok for me, just that one package does use another formatting than another package makes it difficult to digest the read versions.