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. 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. 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.
So at this time, I think we basically have three ways of dealing with
this:
1. Add a protective diversion for the affected locations (and keep that
until forky at least).
2. Ship the affected symlinks as directories in some essential package
until we are sure that no package ships these directories (even in
external repositories).
3. Modify dpkg in some way to handle this case.
I hope this made things more clear. Also note that this mail is purely
concerned with dpkg package operations and entirely ignores the
bootstrap use case.
My takeaway here is that while I see the protective diversion as the
"obviously superior solution", this clearly is not consensus at this
time. It also means that when rewriting DEP 17, I need to spend quite a
bit of text on rationale. Thank you.
Helmut
[1] https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking
