"Theodore Ts'o" <ty...@mit.edu> writes: > On Wed, Feb 15, 2023 at 04:06:55PM -0700, Sam Hartman wrote:
>> You argue about shared libraries for non-packaged binaries. I think we >> mostly don't care about that, and again, I think that's at least a >> generally recognized thing that came out of our focus on packages and >> package dependencies. > Note that package dependencies doesn't allow a binary created on Debian > N to work on Debian N-1. It just *prevents* the package from being > installed on Debian N-1. If you care about allowing the package to be > instaslled on Debian N-1, that's what build chroots are for. That's how > we create packages for backports, after all. > I'm making a similar argument for mkfs and bootable images for older > distributions. Just as you use a build chroot when you build a package > for Debian N-1, you should use a chroot when building a bootable image > for Debian N-1. And that means using the chroot for *everything*; not > just installing the grub bootloader, but also running mkfs. Regardless of which analogy feels more correct here, the reality on the ground is that using a current mke2fs to create file systems for older Debian versions, unlike running new binaries on old systems, is something that used to work. People have been doing that and relied on it working. We've made a change that broke it. That change has benefits and justifications as all changes do, but from the perspective of the people with that use case, it's a regression. So we should either document it or revert it, and I think the debate is over which of those two to do. Ideally we do this with an eye to what reduces this problem in the future. It had never occurred to me before that the version of the system on which I run mke2fs would matter as long as I didn't pick a newer file system type (ext5 or something). Now I know! Until today, I had no idea ext4 even *had* "incompat" features or that mke2fs could make file systems that grub couldn't understand. I'm sure this is well-documented in the ext4 world (although ext4(5) could both be advertised a bit more prominently and be more explicit about this problem, IMO). I'd just never had any reason to seek out that documentation, since creating file systems with the defaults has always just worked for me. In that sense, it's a testament to the maintenance quality of ext4, but the result of mke2fs just working all these years is that most users do not read the details of the ext4 man page since they've never needed to. That would make me lean towards making documentation a large part of the solution here. I'm sure I'm not alone in having no idea that the version or configuration of mk2efs mattered at this level unless I'd changed the defaults. It seems like we'd save people a lot of future trouble if we could find ways to communicate to system constructors that the file system needs to be built from a chroot. In other words, if this is a compatibility rule that is important when using these tools, it needs to be WAY more prominently documented than it is right now. That that feels more important to me than adding a one-release backward-compatibility guarantee. A lot of environments regularly use oldstable or even oldoldstable for specific applications, so we'd still break people's use cases if they don't know about the need to build file systems from a chroot. Given that this will presumably happen again in the future since it's apparently a normal part of ext4 development, it's not a one-time problem and it's something that we somehow have to communicate to users to avoid ongoing fragility. It feels to me (not a release team member!) like the strongest argument for making a change other than documentation is the proximity to the release at which the change was made (which is indeed quite late in the release process for this critical of a component of the operating system). But I'm also not sure that matters to most of our users? I think most users are only going to care when stable is released; people doing production work on unstable or testing already know that they're signing up for occasional breakage. So the proximity-to-release argument to me feels most relevant if this change is specifically a problem for the release process and would hold up things Debian itself needs to do, due to (for example) it being difficult to change tooling so that file systems are generated from a chroot. I have no idea if that's the case. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
