Sam Hartman <hartm...@debian.org> writes: > * Anyone could prepare patches to image building software to use mkfs > options that will work with bullseye. You could also try to prepare > patches to run mkfs out of a chroot or container of the guest OS for > the image. I appreciate Russ strongly favors this solution, but as > someone who has dug into image building tools a fair bit over the > years, I think there are significant complexity and performance > downsides to that approach. I also think that changing the mkfs > options is more likely to get an unblock than changing the structure > of how the tool works.
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. I suspect this won't be Ted's favorite option because this isn't a natural way to think about the option space from a file system developer perspective, but maybe we could find some compromise along those lines? -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
