kbuild: Restore .version auto-increment behaviour for Debian packages

  Since 2df8220cc511 ("kbuild: build init/built-in.a just once"),
generating Debian packages using 'make bindeb-pkg' results in
packages that are stuck to the same .version, leading to unexpected
behaviours (multiple packages with the same version).

That's because the mkdebian script samples the build version
before building the kernel, and forces the use of that version
number for the actual build.

Restore the previous behaviour by calling init/build-version
instead of reading the .version file. This is likely to result
in too many .version bumps, but this is what was happening before
(although the bump was affecting builds made after the current one).

Eventually, this script should be turned into something that
is a bit less counter-intuitive (building the kernel first
and only then generating the packaging artefacts).

Fixes: 2df8220cc511 ("kbuild: build init/built-in.a just once")
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Nick Desaulniers <ndesaulniers@google.com>
---

Notes:
    v2: Drop the RPM version which was wrong, and make the path
        relative to $srctree.

 scripts/package/mkdebian | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

On Wed, Nov 16, 2022 at 7:05 AM Marc Zyngier <maz@kernel.org> wrote:
>
> Since 2df8220cc511 ("kbuild: build init/built-in.a just once"),
> generating Debian packages using 'make bindeb-pkg' results in
> packages that are stuck to the same .version, leading to unexpected
> behaviours (multiple packages with the same version).
>
> That's because the mkdebian script samples the build version
> before building the kernel, and forces the use of that version
> number for the actual build.
>
> Restore the previous behaviour by calling init/build-version
> instead of reading the .version file. This is likely to result
> in too many .version bumps, but this is what was happening before
> (although the bump was affecting builds made after the current one).


What do you mean by "too many .version bumps"?

Every "make bindeb-pkg" increments the version by one.

Is there any case where it increases more?





> Eventually, this script should be turned into something that
> is a bit less counter-intuitive (building the kernel first
> and only then generating the packaging artefacts).


How to achieve this?

The version is recorded in debian/chanegelog.
Without it, dpkg-buildpackage fails.

In my understanding, the version must be fixed before building the kernel.








>
> Fixes: 2df8220cc511 ("kbuild: build init/built-in.a just once")
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Cc: Masahiro Yamada <masahiroy@kernel.org>
> Cc: Michal Marek <michal.lkml@markovi.net>
> Cc: Nick Desaulniers <ndesaulniers@google.com>
> ---
>
> Notes:
>     v2: Drop the RPM version which was wrong, and make the path
>         relative to $srctree.
>
>  scripts/package/mkdebian | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/package/mkdebian b/scripts/package/mkdebian
> index 60a2a63a5e90..a3ac5a716e9f 100755
> --- a/scripts/package/mkdebian
> +++ b/scripts/package/mkdebian
> @@ -90,7 +90,7 @@ if [ -n "$KDEB_PKGVERSION" ]; then
>         packageversion=$KDEB_PKGVERSION
>         revision=${packageversion##*-}
>  else
> -       revision=$(cat .version 2>/dev/null||echo 1)
> +       revision=$($srctree/init/build-version)
>         packageversion=$version-$revision
>  fi
>  sourcename=$KDEB_SOURCENAME
> --
> 2.34.1
>


--
Best Regards
Masahiro Yamada
  

On Wed, 16 Nov 2022 06:09:31 +0000,
Masahiro Yamada <masahiroy@kernel.org> wrote:
> 
> On Wed, Nov 16, 2022 at 7:05 AM Marc Zyngier <maz@kernel.org> wrote:
> >
> > Since 2df8220cc511 ("kbuild: build init/built-in.a just once"),
> > generating Debian packages using 'make bindeb-pkg' results in
> > packages that are stuck to the same .version, leading to unexpected
> > behaviours (multiple packages with the same version).
> >
> > That's because the mkdebian script samples the build version
> > before building the kernel, and forces the use of that version
> > number for the actual build.
> >
> > Restore the previous behaviour by calling init/build-version
> > instead of reading the .version file. This is likely to result
> > in too many .version bumps, but this is what was happening before
> > (although the bump was affecting builds made after the current one).
> 
> 
> What do you mean by "too many .version bumps"?
> 
> Every "make bindeb-pkg" increments the version by one.

And isn't that a problem? We increase the build number pointlessly,
even if there is *nothing* to change.

> 
> Is there any case where it increases more?

No, but that's bad enough IMHO.

> > Eventually, this script should be turned into something that
> > is a bit less counter-intuitive (building the kernel first
> > and only then generating the packaging artefacts).
> 
> 
> How to achieve this?


By building the kernel *before* sampling the version number, just like
RPM does.

> 
> The version is recorded in debian/chanegelog.
> Without it, dpkg-buildpackage fails.

And again, nothing forces us to do it in that order.

> In my understanding, the version must be fixed before building the kernel.

Can't immediately see what mandates it, but I'm sure you know better.

Anyway, the current situation needs fixing. If you're unhappy with the
patch, feel free to replace it with something that you consider more
appropriate.

	M.
  

On Wed, Nov 16, 2022 at 9:28 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 16 Nov 2022 06:09:31 +0000,
> Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Wed, Nov 16, 2022 at 7:05 AM Marc Zyngier <maz@kernel.org> wrote:
> > >
> > > Since 2df8220cc511 ("kbuild: build init/built-in.a just once"),
> > > generating Debian packages using 'make bindeb-pkg' results in
> > > packages that are stuck to the same .version, leading to unexpected
> > > behaviours (multiple packages with the same version).
> > >
> > > That's because the mkdebian script samples the build version
> > > before building the kernel, and forces the use of that version
> > > number for the actual build.
> > >
> > > Restore the previous behaviour by calling init/build-version
> > > instead of reading the .version file. This is likely to result
> > > in too many .version bumps, but this is what was happening before
> > > (although the bump was affecting builds made after the current one).
> >
> >
> > What do you mean by "too many .version bumps"?
> >
> > Every "make bindeb-pkg" increments the version by one.
>
> And isn't that a problem? We increase the build number pointlessly,
> even if there is *nothing* to change.


I think "make *-pkg" should increment the version every time.


The .version is incremented only when vmlinux is updated.

When you change module code, only *.ko is relinked.
The .version stays because it is embedded in vmlinux.


Even if you build the kernel first, and .version has no change,
the package contents may have some changes.





> >
> > Is there any case where it increases more?
>
> No, but that's bad enough IMHO.
>
> > > Eventually, this script should be turned into something that
> > > is a bit less counter-intuitive (building the kernel first
> > > and only then generating the packaging artefacts).
> >
> >
> > How to achieve this?
>
>
> By building the kernel *before* sampling the version number, just like
> RPM does.
>
> >
> > The version is recorded in debian/chanegelog.
> > Without it, dpkg-buildpackage fails.
>
> And again, nothing forces us to do it in that order.
>
> > In my understanding, the version must be fixed before building the kernel.
>
> Can't immediately see what mandates it, but I'm sure you know better.
>
> Anyway, the current situation needs fixing. If you're unhappy with the
> patch, feel free to replace it with something that you consider more
> appropriate.
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.
  

On Wed, 16 Nov 2022 20:56:38 +0000,
Masahiro Yamada <masahiroy@kernel.org> wrote:
> 
> On Wed, Nov 16, 2022 at 9:28 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 16 Nov 2022 06:09:31 +0000,
> > Masahiro Yamada <masahiroy@kernel.org> wrote:
> > >
> > > On Wed, Nov 16, 2022 at 7:05 AM Marc Zyngier <maz@kernel.org> wrote:
> > > >
> > > > Since 2df8220cc511 ("kbuild: build init/built-in.a just once"),
> > > > generating Debian packages using 'make bindeb-pkg' results in
> > > > packages that are stuck to the same .version, leading to unexpected
> > > > behaviours (multiple packages with the same version).
> > > >
> > > > That's because the mkdebian script samples the build version
> > > > before building the kernel, and forces the use of that version
> > > > number for the actual build.
> > > >
> > > > Restore the previous behaviour by calling init/build-version
> > > > instead of reading the .version file. This is likely to result
> > > > in too many .version bumps, but this is what was happening before
> > > > (although the bump was affecting builds made after the current one).
> > >
> > >
> > > What do you mean by "too many .version bumps"?
> > >
> > > Every "make bindeb-pkg" increments the version by one.
> >
> > And isn't that a problem? We increase the build number pointlessly,
> > even if there is *nothing* to change.
> 
> 
> I think "make *-pkg" should increment the version every time.

But that's not what the rpm package builder does.

> 
> 
> The .version is incremented only when vmlinux is updated.
> 
> When you change module code, only *.ko is relinked.
> The .version stays because it is embedded in vmlinux.
> 
> 
> Even if you build the kernel first, and .version has no change,
> the package contents may have some changes.

And again, isn't that an inconsistency?

Anyway, enough idle arguing. What do want me to do about this bug?

	M.
  

On Thu, Nov 17, 2022 at 6:40 AM Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 16 Nov 2022 20:56:38 +0000,
> Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Wed, Nov 16, 2022 at 9:28 PM Marc Zyngier <maz@kernel.org> wrote:
> > >
> > > On Wed, 16 Nov 2022 06:09:31 +0000,
> > > Masahiro Yamada <masahiroy@kernel.org> wrote:
> > > >
> > > > On Wed, Nov 16, 2022 at 7:05 AM Marc Zyngier <maz@kernel.org> wrote:
> > > > >
> > > > > Since 2df8220cc511 ("kbuild: build init/built-in.a just once"),
> > > > > generating Debian packages using 'make bindeb-pkg' results in
> > > > > packages that are stuck to the same .version, leading to unexpected
> > > > > behaviours (multiple packages with the same version).
> > > > >
> > > > > That's because the mkdebian script samples the build version
> > > > > before building the kernel, and forces the use of that version
> > > > > number for the actual build.
> > > > >
> > > > > Restore the previous behaviour by calling init/build-version
> > > > > instead of reading the .version file. This is likely to result
> > > > > in too many .version bumps, but this is what was happening before
> > > > > (although the bump was affecting builds made after the current one).
> > > >
> > > >
> > > > What do you mean by "too many .version bumps"?
> > > >
> > > > Every "make bindeb-pkg" increments the version by one.
> > >
> > > And isn't that a problem? We increase the build number pointlessly,
> > > even if there is *nothing* to change.
> >
> >
> > I think "make *-pkg" should increment the version every time.
>
> But that's not what the rpm package builder does.
>
> >
> >
> > The .version is incremented only when vmlinux is updated.
> >
> > When you change module code, only *.ko is relinked.
> > The .version stays because it is embedded in vmlinux.
> >
> >
> > Even if you build the kernel first, and .version has no change,
> > the package contents may have some changes.
>
> And again, isn't that an inconsistency?


Yes, it is inconsistent.
Basically, I want all *-pkg targets working in the same way.
Changing binrpm-pkg is easy (Bump the version first),
but the opposite way is impossible (at least, I cannot come
up with a good solution).


>
> Anyway, enough idle arguing. What do want me to do about this bug?
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.


I dropped the last paragraph, and applied. Thanks.