On 2023-06-10 10:39 +0200, Helmut Grohne wrote: > Hi Sven, > > On Sat, Jun 10, 2023 at 08:35:44AM +0200, Sven Joachim wrote: >> > Unfortunately, any >> > external package that still ships stuff in /bin breaks this. In effect, >> > any addon repository or old package can break your system. >> >> You lost me. We have converted /bin to a symlink already, have many >> packages that ship files there and yet our systems do not break. Could >> you please elaborate? > > I'm sorry. I see how I am mixing up use cases all the time. What is > broken here is smooth upgrades (or package removal). Let me add detail. > > dpkg has two kinds of filesystem resources. These are owned objects and > shared objects. A regular file usually is owned by one and only one > package. A directory is often shared between multiple packages. A > regular file can also be shared between multiple (Multi-Arch: same) > instances of the same package. So whenever a package removes a shared > object from a package (due to upgrading or removing the package), dpkg > checks whether this shared object now is unreferenced. If that happens, > it actually deletes it from the filesystem. > > So we kinda need to distinguish the actual filesystem view from the dpkg > database view in this discussion. While the filesystem can now (since > bookworm) be assumed to always have the symlinks, dpkg has a (shared) > object there. It doesn't track the type yet (though Guillem is > working[1] on that). > > Now we imagine a situation where we managed to get past this transition > somehow and the end state is that no package in trixie ships /bin other > than base-files, which ships it as a symlink.
That is what I would perceive as the goal. In this case, the /bin symlink is safe from being removed by dpkg since it is owned by a package. Or am I missing something? > Or maybe we finished the > transition by having no package ship /bin and we modified the bootstrap > protocol to create the symlinks in another way. I don not think this is possible, for the two reasons you gave below. > There is two use cases that are at risk now: > > * You have some old bookworm package around that still ships a file in > /bin. You no longer need this package and remove it. Since this was > the last package (on your system) to contain /bin (in data.tar), dpkg > observes that /bin can go away and deletes your symlink. Boom. > > * You have some external repository that contains a package which still > ships something in /bin. At some point the vendor got the message > about moving files and moves them to /usr/bin and this - again - is > when your /bin symlink vanishes during the package upgrade. Cheers, Sven