Message-ID: <20230328040917.GC108653@mit.edu>
Date:   Tue, 28 Mar 2023 00:09:17 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: Change in kernel debian packages between -rc2 and -rc3

On Mon, Mar 27, 2023 at 10:35:09PM +0900, Masahiro Yamada wrote:
> 
> 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.

Well, for me, technically speaking CONFIG_LOCAVERSION *does* specify
an module ABI.  I have a install-kconfig[1] which is **different**
from what I might use in other contexts (for example, when building a
custom kernel for my laptop and desktop).  And in fact, there are two
flavors, with different kernel configs --- and hence, different and
incompatible module ABI's.  "xfstests"[2] and "xfstests-perf"[3]

[1] https://github.com/tytso/xfstests-bld/blob/master/kernel-build/install-kconfig
[2] https://github.com/tytso/xfstests-bld/blob/master/kernel-build/kernel-configs/config-6.1
[3] https://github.com/tytso/xfstests-bld/blob/master/kernel-build/kernel-configs/perf-config-6.1

And since they are different ABI's, and I want to distinguish between
them in the package name, so I can keep them straight --- and in
theory, there would be nothing wrong with wanting to have both an
"xfstests" and "xfstests-perf" installed at the same time, and being
able to select between the two of them using a bootloader.

Ergo, in my case CONFIG_LOCAVERSION is *part* of the version, and it
is a **feature*** that package names should include the
CONFIG_LOCALVERSIONS --- because they are different kernels, with
different properties!


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

It's still a backwards incompatible change.  And Linus doesn't like
backwards compatible changes which is noticeable, even if it's
something which isn't promised in, say, the POSIX spec.  If we change
kernel behavior, and it's noticeable, it's BAD BAD BAD.  I would claim
the same is true for kbuild infrastructure, unless there's a really
good reason.


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

KDEB_PKGVERSION is not documented anywhere.  Thank you for telling me
about it, though.

I'd suggest that perhaps KDEB_PKGVERSION is documented, so there is an
explicit promise that this interface will be preserved?  I would hate
for you to later change, and break me, and claim "nobody promised",
since it's not documented.

And if you really want users to be able to replicate a Debian kernel's
"module ABI", then I'd **strongly** suggest that you document how they
are supposed to do that.  After all, Debian and Ubuntu doesn't use the
kbuild infrastructure; they have their own hugely complicated way of
generating files.

And oh by the way, I've just looked up Debian's documentation on that,
and the "ABI name" is not just the kernel version.  So it's not just
(for example) "2.6.18", but "2.6.18-1-686".   See [2].

[2] https://wiki.debian.org/DebianKernelABIChanges

And if you are going to be including the full git commit id in the
version, e.g., "6.3.0-rc3-00043-g463f2e46bf7c", it's not going to be
compatible with the Debian kernel ABI name ***anyway***.  So it's also
equally broken in terms of hwo Debian does things.


> They are enough to continue your broken workflow.

Well, for upstream developers, it's very useful to be able to
distinguish between kernel configs and this very *much* implicates the
"module ABI".  So IMHO think my particular use case is not "broken",
but in fact essential.

There are Very Good Reasons for doing things in this particular way.

      	       	    	    	      - Ted

P.S.  I actually simplified the story a little bit; there are actually
quite a lot more possible "module ABI's", or "kernel configs" than
just the two "xfstests" and "xfstests-perf".  These are all valid
install-kconfig commands:

# This will produce a CONFIG_LOCALVERSION of "xfstests-blktests"
% install-kconfig --blktests

# This will produce a CONFIG_LOCALVERSION of "xfstests-perf-kasan"
% install-kconfig --perf --kasan

# This will produce a CONFIG_LOCALVERSION of "xfstests-dept"
% install-kconfig --dept

# This will produce a CONFIG_LOCALVERSION of "xfstests-debug-lockdep"
% install-kconfig --debug --lockdep

etc.

These are all different kernel configs, producing different "module
ABI"'s, and I want to be able to distinguish between them in the
generated package files!

Powered by blists - more mailing lists