Hi Richard, On Fri, Jun 09, 2023 at 01:07:13PM -0500, Richard Laager wrote: > On 2023-06-09 11:26, Helmut Grohne wrote: > > When upgrading (or > > removing that package), dpkg will attempt to remove /bin (which in its > > opinion is an empty directory and the last consumer is releasing it). > > However, since dpkg has no clue about file types, it doesn't actually > > know that this is a directory and takes care of the /bin -> /usr/bin > > symlink using unlink(). And this is where /bin vanishes. Oops. > > This might be a dumb question, but could we just special-case this? That is, > dpkg would simply not remove /bin specifically? If the list of directories > is small, known, and relatively fixed (e.g. /bin, /usr/bin, /lib), that > might be workable.
Even if this was a dumb question, it's these kind of questions that - surprisingly often - lead to new insights. So thanks for asking. I caution that this protection mechanism of symlinks is a property of the installation and not of dpkg. Depending on what dpkg is operating on, we expect it to handle this or not. So we'd need a way to tell whether an installation needs this kind of special handling. Anyway, let's for now just assume that magically dpkg would magically save those symlinks when we want to save them. Now any package that moves files from / to /usr, needs to ensure that the dpkg doing that move is recent. That's a dependency we cannot express in theory. David Kalnischkies spent some time going into detail[1] about this aspect. I think the bottom line is that for all practical purposes we're probably fine if everything that moves also gains a Pre-Depends on dpkg. Except that dpkg Pre-Depends on libc6, which would now Pre-Depends: dpkg and we're back to our Pre-Depends loop. So now we say "screw it" and let libc6 get a pass without this Pre-Depends, because so many packages already have a Pre-Dependency on dpkg, it'll probably get upgraded early and what could possibly go wrong? On amd64, we'd upgrade libc6 before dpkg and then /lib64 would go missing, because libc6 already is the last package that ships files in /lib64. So really, libc6 is one of the few packages that really must depend on that fixed dpkg. It also is one of the few packages that really cannot. As we cannot get out of this loop, we consider stretching the transition over two releases. For trixie, we just update dpkg without moving files and then for the trixie -> forky upgrade, we know (since we forbid skip upgrades) that dpkg is fixed and then it actually works out without this mess of Pre-Depends on dpkg. My impression is that we'd like to have this done sooner rather than later. At this time, the protective diversion seems like a fairly easy and reliable mitigation with little downsides (except for having a new transitively essential package) that helps us move forward faster. Please don't stop asking. The chances that something about this is wrong or missing something is significantly non-zero. I hope that this kind of peer-review will get us to a solution that actually works in practice. Helmut [1] https://lists.debian.org/20230503130026.ixu4zlymo4fykdru@crossbow
