On Tue, Feb 14, 2023 at 08:46:53PM -0500, Theodore Ts'o wrote:
>...
> I will draw the analogy of building a program which links against
> glibc for Bookworm resulting in a binary that will not run on Buster.
> We expect that, and we tell people to use build chroots. This is not
> something which is actionable, and we don't hold back glibc updates
> just because you can no longer build on Debian 10.0 something that
> won't work on Debian 9.0, or 8.0.
>...
> We can change the default for mke2fs.conf file for Debian. I don't
> think it's warranted, and I'm not aware of any other distribution
> doing this. The fact that file system featuers that fix certain
> problems (such as the 2038 bug) will cause older versions the
> distribution to fail to accept that file system is always going to be
> the case. So how long do we hold back some new feature? A year? Two
> years? Five years? Ten years? Again, we don't do this with shared
> library linkages; we just tell people to use a build chroot.
>...
> So if we are to hold e2fsprogs and xfsprogs to the standard that a
> file system created by default must work on all older Debian and
> Ubuntu distributions to some arbitrary point in history,
>...
A rule of thumb is that any combination/mix of packages permitted by the
package manager from two adjacent Debian releases should work whenever
reasonably possible, since this reduces problems for our users during
an upgrade, when using backports, or when temporarily going back to the
version of a package from the previous stable due to a regression.
For normal library dependencies
Depends: libc6 (>= 2.34)
will do the right thing automatically.
e2fsprogs adding Breaks against older versions of bootloaders and other
software that lacks support for the new default might be a good idea.
The situtation is different when a relationship cannot be reliably
expressed by package dependencies.
For the kernel the answer to your "how long" is that packages should
also work with the kernel from the previous and the kernel from the
next Debian release.
Some time ago there was a discussion regarding Qt in Debian 10 using the
getrandom syscall that was not available in the kernel in Debian 8.
This was not considered supported (or supportable) since Debian 8 and
Debian 10 are not adjacent releases, but Qt in Debian 10 using a feature
not supported by the kernel in Debian 9 might have resulted in a lot of
problems when still running the old kernel during or after an upgrade
from Debian 9 to Debian 10.
If the feature stays enabled by default in bookworm:
Everyone using grub is an x86 thing, for embedded ARM it is more common
to use a once ported ancient u-boot on your hardware forever.[1]
A bug against the release-notes pseudo-package with text describing
the incompatibility and possible workarounds would be appreciated.
> Best regards,
>
> - Ted
cu
Adrian
[1] u-boot in bullseye does already "support" metadata_csum_seed
by refusing to write to filesystems that have it enabled:
https://salsa.debian.org/debian/u-boot/-/commit/2e7365518acdb8fb6e9be332c8a6c57b457188d9
