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@weissschuh.net>
Signed-off-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>
---
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@freenet.de/

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')"
 # The PKGBUILD is evaluated multiple times.
 # Running scripts/build-version from here would introduce inconsistencies.
 pkgrel="${KBUILD_REVISION}"

---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731

Best regards,
Viktor
-- 
2.54.0

On Fri, 15 May 2026 23:58:45 +0200, 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.
> 
> [...]

Applied to kbuild/linux.git (kbuild-fixes-unstable), thanks!

[1/1] kbuild: pacman-pkg: make "rc" releases adhere to pacman versioning scheme
      https://git.kernel.org/kbuild/c/f2be8dd2

Please look out for regression or issue reports or other follow up
comments, as they may result in the patch/series getting dropped,
reverted or modified (e.g. trailers).  Patches applied to the
kbuild-fixes-unstable branch are accepted pending wider testing in
linux-next and any post-commit review; they will generally be moved
to the kbuild-fixes branch in a week if no issues are found.

Best regards,
-- 
Nicolas

On Fri, May 15, 2026 at 11:58:45PM +0200, 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@weissschuh.net>
> Signed-off-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>

Nicolas, do you want to take this as a fix for 7.1 (since it seems
reasonable to correct this for folks building from upstreaam sooner
rather than later)? If so:

Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>

Otherwise, I can pick it up for 7.2 when I am fully back online in a
couple of days.

> ---
> 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@freenet.de/
> 
> 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')"
>  # The PKGBUILD is evaluated multiple times.
>  # Running scripts/build-version from here would introduce inconsistencies.
>  pkgrel="${KBUILD_REVISION}"
> 
> ---
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> 
> Best regards,
> Viktor
> -- 
> 2.54.0

-- 
Cheers,
Nathan

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@weissschuh.net>
> Signed-off-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>
> ---
> 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@freenet.de/
> 
> 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.

Best regards,
Viktor

>  # The PKGBUILD is evaluated multiple times.
>  # Running scripts/build-version from here would introduce inconsistencies.
>  pkgrel="${KBUILD_REVISION}"
> 
> ---
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> 
> Best regards,
> Viktor

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@weissschuh.net>
> > Signed-off-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>
> > ---
> > 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@freenet.de/
> > 
> > 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

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 :)

-- 
Cheers,
Nathan

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@weissschuh.net>
>>> Signed-off-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>
>>> ---
>>> 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@freenet.de/
>>>
>>> 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/'
> 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'.

Best regards,
Viktor

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@weissschuh.net>
> >>> Signed-off-by: Viktor Jägersküpper <viktor_jaegerskuepper@freenet.de>
> >>> ---
> >>> 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@freenet.de/
> >>>
> >>> 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

On 2026-05-17 14:00:56+0900, Nathan Chancellor wrote:
> 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:

(...)

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

I agree with Nathan here, let's keep it simple.


Thomas