linux-kernel - Re: [PATCH] kbuild: Restore .version auto-increment behaviour for Debian packages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 16 Nov 2022 12:28:04 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
        Michal Marek <michal.lkml@...kovi.net>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH] kbuild: Restore .version auto-increment behaviour for Debian packages

On Wed, 16 Nov 2022 06:09:31 +0000,
Masahiro Yamada <masahiroy@...nel.org> wrote:
> 
> On Wed, Nov 16, 2022 at 7:05 AM Marc Zyngier <maz@...nel.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.

-- 
Without deviation from the norm, progress is not possible.