Re: booststrapping /usr-merged systems
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
Reply to: