Message-ID: <CAK7LNARcUSsjzi7UV+rHHaQU1X-XJ0jN0sLAw2m=SypTQTCHKA@mail.gmail.com>
Date:   Mon, 27 Mar 2023 22:35:09 +0900
From:   Masahiro Yamada <masahiroy@...nel.org>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Change in kernel debian packages between -rc2 and -rc3

On Sun, Mar 26, 2023 at 9:11 PM Theodore Ts'o <tytso@....edu> wrote:
>
> On Sun, Mar 26, 2023 at 12:39:44PM +0900, Masahiro Yamada wrote:
> >
> > I am afraid you are completely misunderstanding the two versions,
> > the ABI version and the package version.
> >
> > They do not need to match. Actually, they do not match.
> >
> > See real Debian (or Ubuntu) systems.
> >
> > `uname -r` returns '5.10.0-21-amd64'.
> > This is what they call the ABI version, and
> > this is contained as a part of the package name,
> > 'linux-image-5.10.0-21-amd64'
>
> That may be a convention that Debian uses, but I'll point out that
> trying to use this as an ABI version when people are using different
> .config's is not going to end well.  That's because many different
> Kernel configurations will end up making incompatible changes to the
> ABI.  and only works if you are ***super*** careful about not making
> any kind of changes (e.g., the number of CPU's, adding or changing
> various cgroup controllers, all of which will make incompatible kernel
> ABI changes.)
>
> This is "Stable ABI nonsense" is well, nonsense.

Well, that is just the _name_.

The actual effect is whether you can install
multiple kernel packages at the same time or not
because the ABI version is a part of the package name.
The ABI is nothing more than that for upstream kernel packages.



>
> > It was _not_ reflected in the package version.
> > This is also correct since the package version
> > is not meant to reflect such user configuration
> > as CONFIG_LOCALVERSION.
>
> Citation, please?  Does the Debian system work in that particular way?


The Debian policy [1] says that the version consists of:

    <upstream_version>-<debian_revision>

For clarification, I omitted <epoch>.


[1] http://www.fifi.org/doc/debian-policy/policy.html/ch-versions.html


See what the Debian source package looks like.

<upstream_version> determines the basename of *.orig.tar.gz.

*.orig.tar.gz is generated by 'git archive'.
Obviously, the output of 'git archive' is the same
as long as you work on the same git commit hash.

Think about doing 'make deb-pkg' multiple times on
commit 463f2e46bf7c.
(for example one for CONFIG_LOCALVERSION="-foo"
the other for CONFIG_LOCALVERSION="-bar")


First run:
linux-upstream_6.3.0-rc3-00043-g463f2e46bf7c.orig.tar.gz  [1]
linux-upstream_6.3.0-rc3-00043-g463f2e46bf7c-1.dsc
linux-upstream_6.3.0-rc3-00043-g463f2e46bf7c-1.debian.tar.xz

Second run:
linux-upstream_6.3.0-rc3-00043-g463f2e46bf7c.orig.tar.gz  [2]
linux-upstream_6.3.0-rc3-00043-g463f2e46bf7c-2.dsc
linux-upstream_6.3.0-rc3-00043-g463f2e46bf7c-2.debian.tar.xz


[1] and [2] are the same
(since it is the output of "git archive 463f2e46bf7c").
Hence, it is shared by multiple packages, no matter how many
you generate from commit 463f2e46bf7c.


You are requiring the file name to contain "-xfstests", "-foo", or "-bar"
depending on the CONFIG options.
There is no room for CONFIG options to affect <upstream_version>.

So, the rule is quite simple.
If the contents are exactly the same, they have the same version.
If they are different, they have different versions.



> In any case, it's an incompatible regression made during rc2 and rc3,
> which I think is at the very least, unfortunate.


Your tool was working on a wrong assumption, which nobody promised.

Kbuild already provides various hooks.
You can use CONFIG options and KERNELRELEASE to override uname,
and use KDEB_PKGVERSION to override the package version.

They are enough to continue your broken workflow.





>
>                                     - Ted
--
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists