>>>>> "Sam" == Sam Hartman <hartm...@debian.org> writes:
Sam> TL;DR: It looks like if we do not want to encode merged /usr Sam> into the bootstrap protocol, we must keep some aliases and Sam> cannot move all files in data.tar. I think removing all Sam> aliasing is important and so I am firmly in the camp of doing Sam> usrmerge in the bootstrap protocol. I was chatting with Klee Dienes this morning about this issue, and we had an interesting discussion I'd like to share here. I want to emphasize that Klee has not been following the discussion, so if he comes up with interesting ways to think about things, great, but he's not currently a participant in trying to come to consensus here. It sounds like we've convinced ourselves we have some sort of technical debt we're going to need to carry from the usrmerge transition, and we probably will never be able able to get away from it: 1) In Bootstrap option 3B, we encode doing the usrmerge symlinks into the bootstrap protocol. Even if we somehow later create the symlinks in a data.tar, we need to retain this debt in the bootstrap protocol as long as we want to be able to bootstrap versions of Debian that do not encode things in data.tar. 2) If we take Bootstrap 3C category 1, and some files never get moved to their canonical path, then we have technical debt we must maintain in essential packages, basically for ever. In effect, there is technical debt because the canonical locations of some files differs from their canonical interface locations. For example, /bin/sh will live at /usr/bin/sh. And as long as that's true (we expect for ever), we have to say that somewhere. Okay, so how do we decide where to put technical debt? Klee argued that one point of lower layers is to make things easier and cleaner for layers above them. I.E. there may be some magic in the bootstrap layer and that's good if it makes things cleaner or more pure for the layer above (the essential packages). Similarly, we put complexity in essential packages and make it easier to write non-essential packages. We've seen this over the years. For example, back in the day, bootstrap had to create devices. It still has to arrange for a /proc and a /sys. We managed to follow this principle by pushing devices down a layer further effectively into the kernel and udev, and because of that bootstrap is simpler than it used to be. But Klee argued that putting this in bootstrap is nice because you can handle it in one place rather than spreading it across every essential package containir a binary that cannot move. One assumption behind 3C at least initially is that we were avoiding a combinatorial explosion in changes to bootstrap tool. That's certainly true in https://lists.debian.org/20230517093036.ga4104...@subdivi.de That message assumes 3B is not really an option, and we're looking at changes to number of bootstrap tools times number of releases of Debian and all its derivatives. But as we've explored, we've learned that the combinatorial explosion is more like 2 (3 if you count cdebootstrap). Josh has agreed that we can implement 3B in a small number of lines of code in the bootstrap implementations, at least if we're willing to require people bootstrapping pre-stretch to say they do not want merged /usr. And so, we can concentrate the complexity of our technical debt into a smaller number of places if we adopt 3B. I also think it is possible (although unlikely) that as maintainer scripts in essential packages change over the years, the number of binaries affected by 3C category 1 may increase. I.E. we may find ourselves moving a binary out of /usr back to /bin or being unable to use that in a future maintainer script. That seems like a mess to me. I agree the set of circumstances where we need to do that is small, but I think itmay be nonzero. --Sam
signature.asc
Description: PGP signature