Hi, On Fri, Nov 19, 2021 at 12:28:56PM -0700, Sam Hartman wrote:
> But we could you know fix dpkg:-) > I'm sure that will be painful at the political level, but personally I > think it needs doing. I think the main blocker at the moment is that the dpkg change *also* has the potential to break a lot of things if it isn't carefully designed. The problem space right now is huge: - for upgraded systems, the system could be pre-usrmerge, or the conversion could have been performed by any usrmerge version that ever existed (and the usrmerge package could have been deinstalled and reinstalled since, so the patches to the conffiles it performs could be inconsistently applied). - for upgraded systems, any version of usrmerge since the last stable release could be installed - for upgraded systems, unless the usrmerge package is discontinued, it could be upgraded at any point during the update. - for freshly installed systems, dpkg is first invoked on a non-usrmerged tree, and should convert the installation as soon as it becomes aware that conversion is desired (which might not be something we want to hardcode in dpkg, but possibly configure from a separate, Debian-specific package like base-files). - for freshly installed systems, initial unpack might be controlled by debootstrap from stable, which is usrmerge aware, so some of its workarounds may be active, and we need to properly capture this state, too. - freshly installed systems might be created with cdebootstrap or multistrap, and could be generated in --foreign mode - the dynamic loader is specified to be on the root filesystem, and that is part of the ABI standard and not under our control, so we cannot get a conflict-free dpkg database in bookworm. >From dpkg's perspective, we now (kind of) change the policy for directory-vs-symlink conflicts, which dpkg currently resolves in favour of the directory. That was done in ancient times because it was somewhat easy to do this in a package by accident. Not sure if that still applies, but if it does, then we need to formulate the new policy so that we don't catch a regression here (which is why my original idea to just ship the symlinks in base-files is a bad idea). >From the way dpkg and the Debian Policy are initially designed, it is obvious to me that they started out as specification documents, and only when these were hammered out, they were poured into code and rules, and we've been operating from that stable base since, with two exceptions where technical facts were created without updating Policy accordingly, and which has both times been controversial. My interpretation of the "political" situation is that we need this to be a group effort, because no single person has the necessary time to do a thorough enough job that they would feel comfortable signing off on it. I'd be reluctant to do so even if I had three months of uninterrupted time -- that's the level of complexity I see here, and I suspect Guillem feels the same. So I believe the way forward will be writing a specification and giving it enough eyeballs to identify problem cases. Finding the adversarial example for the status quo was easy, since I had to find just one -- the goal now is to get to a state where we don't find such an example easily anymore. The specification should explain how the transition can be finished with the bookworm release for all the different ways packages can be installed, and it should describe the necessary code changes and new test cases to get full coverage, and the document should be signed off by multiple people who jointly take responsibility, to avoid placing all of that on a single person -- because that's what's impeding progress right now, that no one wants to be that person or even feels able to. The description of the problem space I put above is likely incomplete and overzealous at the same time (for example, I haven't checked how different the previous usrmerge packages are, and which of them ever made it into a stable release), so this is also just a starting point. I'll happily spend time refining this or any other proposal, but I'm too time-constrained to be the main driving force here -- this is not my day job, after all. Simon
