On Thu, Feb 16, 2023 at 11:45:23AM -0800, Russ Allbery wrote: > > Yes, I'm probably understating the difficulty of making this change in > practice inside image building software as it's currently constructed. > > My concern about changing mkfs options is that I worry that this would be > a constantly-changing target that has to be synchronized across multiple > pieces of software that are not currently well-aligned with file system > development. One thing that would make this much easier would be for mkfs > to support some sort of compatibility level flag that sets all of the > options, whatever they may be, to their defaults as of some point in the > past. Image building software could then pick a conservative default set > point when building images for older distributions. That change still has > to be added to all of the image building software, but it might be easier > than building a local chroot of the target distribution before using it to > build the file system the actual installation is going into.
As a long-term solution, one could image changing the various image creation tools to do something like "mfks.ext4 -T grub2_dumbdown /dev/XXX", and then have something like the following in /etc/mke2fs.conf: [fs_types] grub2_dumbdown = { features = ^metadata_csum_seed,^casefold } If you care about being able to run fsck.ext4 on really old distributions, one could even add things like [fs_types] jessie_dumbdown = { features = ^metadata_csum_seed,^metadata_csum } etc. Maintaining this would be a nightmare, and I'd want to ask for help, since this would be change if we also want to add dumbdown file system usage types for Ubuntu, and potentially, other Debian derivitives. Even if we stick with grub2_dumbdown, again, how far back do we go? Some people have said, "just one release", but I bet there will be people wanting to create Stretch installer images using a sid userspace. So I'd want to have some kind of formal understanding about what it is that we feel obliged to support. Given the number of users of the iamge building tools, it's a pretty specialized use case with not a lot of users, and they can also just edit /etc/mke2fs.conf to have their favored default. From my e2fsprogs maintainers hat on, that's my position --- I interpret "users" in the Debian Social Contract for the general users, and not necessarily something that needs to work for every single exotic use case, especially if they tend to be more of the power users. If we're not allowed to inconvenience *any* users, then it's hard to make forward progress. Certainly some people (including myself) were inconvenienced for things like /usr-unification and the transition to systemd. We went ahead with the transition even though some users were inconvenienced. And quite honestly, if a few power users need to edit /etc/mke2fs.conf to remove metadata_csum_seed because they want to do something which is *REALLY* not a good idea (using Debian M to build a file system meant for use on Debian M-X) --- for *ALL* file systems, not just ext4. It may be that some users have gotten lucky, and it mostly works. But it's a bad idea, and encouraging this bad practice is eventually going to lead to tears. But, if the Debian Release team would like to override my position, my suggestion would be to just change the default for /etc/mke2fs.conf for *everyone* running Debian bookworm, and with the understanding that this will be reverted in Debian testing after the next stable release, and that moving forward, we make it the image building tools problem if they want to support this highly dubious practice of using Debian N+X's mkfs to build images for Debian N. I would strongly suggest that they figure out which file system features they need to explicitly turn off for ext4, xfs, btrfs, etc., if they want to build old distro versions using whatever random software they have installed on their desktop. Best release engineering practice is that you use a known, controlled build environment, and not whatever random package versions might be on your desktop. While that might be "inconvenient" when building packages, we've learned to live with it. I use sbuild; others might use pbuild, or their own custom schroot setup. But I dare say all responsible people doing release engineering use a known build environment. Why should this be any different if you are building images --- especially images that you expect *your* users or customers to be depending on? What are your responsibilities to them? (Whether or not the Debian Social contract applies to them or not.) - Ted