There is more about this in the referenced bugs, but I dispute
Daniel's characterization of the issue.
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.
The same is true for file system featuers. We add new features to
improve the user experience. This is true for all file systems: ext4,
xfs, btrfs. For example, in Bookworm, the version of xfsprogs is
going to enable the incompat "bigtime" feature for the first time.
This fixes XFS's 2038 problem. A file system has the bigtime feature
enabled won't boot on Grub versions older than 2.06. That is just the
way of the world.
As it truns out, for e2fsprogs, users (or distributions) can very
easily change the default file system features by editing the
configuration file /etc/mke2fs.conf. So if a user wants to ask mke2fs
to disable certain features by default, and "dumb down" the
capabilities of the file system, they can to do that --- on the
command line, by tuning the file system after the fact, or by editing
the /etc/mke2fs.conf file. They can even set the MKE2FS_CONFIG
environment variable to point at their own custom config file if they
would like.
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.
I would gently suggest that the most general solution to this problem
is to do the same for building VM images, if people won't want to be
bothered to learn how to configure the mfks program. After all,
according to popcon, there are 960 times as many people who have use
gcc-10 recently (7685) as vmdb2 (8).
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, should we
1000 times as much hold gcc-10 and clang to the same standard?
Obviously, that is a ridiculous thing to do.
Best regards,
- Ted
