Messages in this thread | | | Date | Tue, 28 Mar 2023 00:09:17 -0400 | From | "Theodore Ts'o" <> | 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!
| |