TL;DR: It looks like if we do not want to encode merged /usr into the bootstrap protocol, we must keep some aliases and cannot move all files in data.tar. I think removing all aliasing is important and so I am firmly in the camp of doing usrmerge in the bootstrap protocol.
>>>>> "Helmut" == Helmut Grohne <hel...@subdivi.de> writes: Helmut> Therefore, my premise of us agreeing on shipping the Helmut> symlinks in base-files likely is wrong despite the number of Helmut> vocal proponents. I think we'd like to do that if we can make it work. I think you convinced us the price of that is too high deep in the message you quote below. >> So I think that to argue for 3C you need a specific proposal >> about what happens. Helmut> https://lists.debian.org/20230517093036.ga4104...@subdivi.de Ah thanks. I will admit that mail didn't get the initial attention it perhaps deserved. And even reading it now I don't see a clearly articulated proposal for 3C. I was put off by a number of things in the mail including the idea that what we now call 3B would require encoding derivative-specific knowledge into the bootstrapping protocol. And so by the time you started talking about specifics of 3C I had already disagreed with enough of the message that I had tuned out. (I made those disagreements clear; my suspicion is that others who also disagreed with other earlier parts of the message tuned out the 3C specifics.) So, my understanding of the specific proposal is that: We in are in category 1: > 1. Don't move. We just keep those files that require a particular > location (such as /bin/sh or the dynamic loader) in their > non-canonical location. As such, maintainer scripts will be able to > run and perform the conversion to symbolic links afterwards. That is, there are some essential files that always remain in non-canonical locations. You also go through some analysis and make it clear that category 2 is fragile: > 2. Move and ship links. Since we unpack all essential data.tar before > running the first maintainer script, having one package contain the > compatibility symlinks is enough to fix the problem. I agree with your analysis that category 2 is fragile. I definitely had not payed adequate attention to this before, even though I did read chunks of the message. My understanding the argument for 3C is roughly the following: >This gets me to the core of my argument: the way that a Debian chroot should >look like should be described by the packages that get installed into the >chroot and not by an outside tool. Yes, an outside tool is needed to do the >installation but that tool should rely on the package metadata to make choices >instead of encoding timestamp or release name dependent codepaths. So it sounds like we are faced with two choices: 1) Keep some aliasing long-term in the data.tar files and get the bootstrap described by the packages rather than by the bootstrap protocol 2) Change the bootstrap protocol and remove aliasing entirely. I am firmly in camp 2. I think that unless we are going to fix dpkg to support aliasing, we need to remove aliasing entirely.
signature.asc
Description: PGP signature