From: Marc Zyngier <maz@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
Michal Marek <michal.lkml@markovi.net>,
Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH] kbuild: Restore .version auto-increment behaviour for Debian packages
Date: Wed, 16 Nov 2022 21:40:04 +0000 [thread overview]
Message-ID: <865yfepoi3.wl-maz@kernel.org> (raw)
In-Reply-To: <CAK7LNATLaT4uwhpT-2o54Z4QjnOcuBDfGwgi-6Jvdr3+SgVo7Q@mail.gmail.com>
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.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2022-11-16 21:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-15 22:04 [PATCH] kbuild: Restore .version auto-increment behaviour for Debian packages Marc Zyngier
2022-11-16 6:09 ` Masahiro Yamada
2022-11-16 12:28 ` Marc Zyngier
2022-11-16 20:56 ` Masahiro Yamada
2022-11-16 21:40 ` Marc Zyngier [this message]
2022-11-17 8:58 ` Masahiro Yamada
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=865yfepoi3.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=ndesaulniers@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox