[pacman-dev] [PATCH] makepkg: treat pkgrel more similarly to pkgver

[Allan McRae]

On 30/08/14 13:56, Luke Shumaker wrote:
> At Fri, 29 Aug 2014 17:16:11 -0500,
> Dan McGee wrote:
>>
>> On Fri, Aug 29, 2014 at 1:07 PM, Luke Shumaker <lukeshu at sbcglobal.net>
>> wrote:
>>
>>> This is perfectly fine with libalpm; it was only makepkg that was more
>>> strict with pkgrel than pkgver.
>>>
>> Correct.
>>
>> However, did you look at the NEWS file? This was an explicit change made in
>> pacman 4.1.0 (commit 708a22757) to tighten the format of this value. I'd be
>> -1 on this change, unless someone can show me a real reason pkgrel should
>> be complicated, given this is something the packager influences and we're
>> not trying to copy or match an upstream value.
> 
> Sorry, I did not catch that in NEWS.
> 
> In my opinion, this is most useful to other distros that are
> downstream from Arch.  For example, in Parabola, packages that are
> repackaged/modified from Arch, they like to set it like
> `pkgrel=${archrel}.${parabolarel}`.  If an Arch package uses both
> places, then Parabola's scheme breaks.  There's also been discussion
> that it would be nice to be able to do
> `pkgrel=${archrel}.parabola${parabolarel}`.
> 
> For kernel modules that must be built against a specific version of
> the kernel, it would be nice to be able to do
> `pkgrel=${_pkgrel}.${_basekernel}`, which would make it so one
> wouldn't have to mess around with pkgrel when just bumping
> _basekernel.
> 
> Sans the desire to stick 'parabola' into pkgrel, I guess at a minimum,
> that really advocates changing it from
> 
>     [[ $i != +([0-9])?(.+([0-9])) ]]
> 
> to
> 
>     [[ $i != +([0-9])*(.+([0-9])) ]]
> 

So that would allow x.y.z pkrels?

>>> Further, the former error message about invalid pkgrel formats claimed that
>>> pkgrel was a "decimal", which would mean that `1.1 == 1.10`.  This was not
>>> the case; alpm parsed pkgrel as a version, not a decimal.  In that light,
>>> enforcing /[0-9]+(\.([0-9]+)?/ on a version spec seems silly.
> 
> If you do reject this change, would you at least accept a patch
> clarifying that it is a simplified 'version', not a decimal?
> 

I'm personally of the opinion that the pkgrel should be a positive
integer and nothing else.  However, I have seen what could be considered
valid uses of the x.y pkgrel - preparing a release and packaging with
0.1, 0.2,...,  and rebuilds that are architecture specific (which is
more of an issue for distributions that have more architectures than
Arch has). So decimals need to stay.g

Saying all of this...   spec files (rpm) often have something like:
Release: 1%{?dist}
where dist is a distribution specific tag.

What I will consider (my mind is changeable):
1) A documentation patch saying pkgrel is an (positive) integer.  A
sub-release (or better name) can be specified by adding another interger
after a period.

2) Inclusion of a "dist" keyword in PKGBUILDs.  If present, this gets
added onto the end of the pkgrel.

Allan