Re: [PATCH v2] kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning scheme

[Nathan Chancellor]

On Sun, May 17, 2026 at 02:57:07AM +0200, Viktor Jägersküpper wrote:
> On 5/16/26 17:33, Nathan Chancellor wrote:
> > On Sat, May 16, 2026 at 04:27:39PM +0200, Viktor Jägersküpper wrote:
> >> On 5/15/26 23:58, Viktor Jägersküpper wrote:
> >>> The package versioning scheme does not enable smooth upgrades from "rc"
> >>> releases to the corresponding stable releases (e.g. 7.0.0-rc7 -> 7.0.0)
> >>> because pacman considers that a downgrade due to the underscore in
> >>> pkgver (e.g. 7.0.0_rc7), see e.g. vercmp(8) for an explanation of the
> >>> package version comparison used by pacman. Package versions which are
> >>> derived from said releases (e.g. built from git revisions) are
> >>> similarly affected. Fix this by modifying pkgver in order to remove the
> >>> hyphen from kernel versions containing "-rcN", where N is a
> >>> non-negative integer.
> >>>
> >>> Acked-by: Thomas Weißschuh <linux@xxxxxxxxxxxxxx>
> >>> Signed-off-by: Viktor Jägersküpper <viktor_jaegerskuepper@xxxxxxxxxx>
> >>> ---
> >>> v1 -> v2:
> >>> - make the substitution more restrictive
> >>> - enhance commit message accordingly
> >>> - add Acked-by tag
> >>>
> >>> v1: https://lore.kernel.org/linux-kbuild/20260513231745.51780-1-viktor_jaegerskuepper@xxxxxxxxxx/
> >>>
> >>> BTW this also works for something like "5.10.248-rt143-rc1" which is a
> >>> recent example of an "rc" release of a realtime kernel.
> >>>
> >>>  scripts/package/PKGBUILD | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/scripts/package/PKGBUILD b/scripts/package/PKGBUILD
> >>> index 452374d63c24..1213c8e04671 100644
> >>> --- a/scripts/package/PKGBUILD
> >>> +++ b/scripts/package/PKGBUILD
> >>> @@ -10,7 +10,7 @@ for pkg in $_extrapackages; do
> >>>  	pkgname+=("${pkgbase}-${pkg}")
> >>>  done
> >>>  
> >>> -pkgver="${KERNELRELEASE//-/_}"
> >>> +pkgver="$(echo "${KERNELRELEASE}" | sed 's/-\(rc[0-9]\+\)/\1/;s/-/_/g')"
> >>
> >> I will send a v3 patch later with the first substitution changed to
> >> match "-rcN" where N is a strictly positive integer because this is
> >> what we really had in the kernel so far, at least as far as I can
> >> remember.
> > 
> > Do you mean dropping the '\+' portion of the regex? If so, I think I
> > would rather keep what you have here since while an -rc10 is incredibly
> > unlikely nowadays (we pretty much never go past -rc8), it has happened
> > once before in 3.1:
> > 
> >   $ git tag -l | grep -- -rc10
> >   v3.1-rc10
> 
> I was only concerned about 'rc0', so I came up with this:
> 
> 's/-\(rc[1-9][0-9]*\)/\1/;s/-/_/g'
> 
> For 'rc' releases starting from 'rc1' this matches '-rcN' where N is a
> strictly positive integer. Since 'git tag -l | grep -- rc0' shows
> nothing, I assume that there is an unwritten rule that counting from 1
> is the correct choice for kernel 'rc' releases. :-)
> 
> Compare that to the Debian substitution code: 's/-\(rc[1-9]\)/~\1/'

While you are correct that the kernel does not use -rc0, I don't think
it is worth preemptively complicating the regex to avoid treating -rc0
differently from -rc1 and beyond; I find the way it is currently written
to be more readable but maybe Christian or Thomas feel differently.

> > We can leave the Debian case you pointed at earlier the way it is for
> > now but if we are making a change here, we might as well make it as
> > future proof as possible. If you (or others) really feel strongly
> > otherwise, feel free to ignore me :)
> Actually I have no preference. If there is consensus that the regex for
> strictly positive integers is better, I can send a v3 patch. The Debian
> code can be adjusted in a follow-up patch.
> 
> BTW I forgot to mention that this patch also addresses the stable 'rc'
> preview releases which also start from 'rc1'.

Ah yes, that is also a good point.

-- 
Cheers,
Nathan