VCS package guidelines

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

VCS package guidelines

Ralf Mardorf
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
Reply | Threaded
Open this post in threaded view
|

Re: VCS package guidelines

Rafael Fontenelle-2
2017-03-08 17:53 GMT-03:00 Ralf Mardorf <[hidden email]>:

> 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

Best regards,
Rafael Fontenelle
Reply | Threaded
Open this post in threaded view
|

Re: VCS package guidelines

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

>2017-03-08 17:53 GMT-03:00 Ralf Mardorf <[hidden email]>:
>
>> 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 ;).
Reply | Threaded
Open this post in threaded view
|

Re: VCS package guidelines

tur-users mailing list
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 <[hidden email]>:
>>
>>> 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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VCS package guidelines

tur-users mailing list
Eli Schwartz via aur-general <[hidden email]> wrote:

> 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 <[hidden email]>:
> >>> 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

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

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.

iff
Reply | Threaded
Open this post in threaded view
|

Re: VCS package guidelines

tur-users mailing list
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VCS package guidelines

Christian Rebischke-2
In reply to this post by tur-users mailing list
On Wed, Mar 08, 2017 at 05:12:19PM -0500, Eli Schwartz via aur-general 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.

cheers,

chris

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VCS package guidelines

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