> Of course, having to unnecessarily add more maintainer scripts to > handle something that dpkg can do perfectly fine on its own
TL;DR: merged-usr-via-symlink-farms cannot be done without changing dpkg,
and since the quote above seems to indicate you'd be willing to do that,
why not just change dpkg to support aliased dirs?
--------------------
Lets look at going forward. We have a problem (Debian supports a mixture
of merged-usr and unmerged-usr layouts). We need to solve this problem,
since the headaches it produces are far worse than either layout on its
own. Let's assume the eventual solution is going to be merged-usr:an
Fact: A significant portion of supported Debian installations currently
use usrmerge, with symlinks between /bin -> /usr/bin, /lib -> /usr/lib,
etc
Any path forward must allow for that. The decisions that caused that fact
to be true are irrelevant: whether or not that fact is a good or bad thing
doesn't matter. What matters is that it is true, and so we need to work
around it, even if the path forward we choose involves reverting it.
It doesn't matter if merged-usr-via-aliased-dirs would have been better if
we'd just done it from the start. It doesn't matter if we could have made
that transition with a small change to debhelper and a release cycle. It
doesn't even matter if the problems we are facing now would never have
occurred with that plan. The fact is true: systems using merged-usr-via-
aliased-dirs exist, and we need to figure out how to go onwards from here.
One way to move forward despite that fact is to mandate running dpkg-fsys-
usrunmess on every system that has a merged-usr layout, and then move
forward from there. However, that script is hardly battle-tested, and
that solution is completely unacceptable to usrmerge proponents. So lets
look at other solutions that would work for everyone.
Another way forward is to transition existing systems without merged-usr
to a merged-usr-via-symlink-farms. To accomplish this, we need the
ability to create symlinks in installations that are not usrmerge, but to
not create those links in installations that are. That requires either
maintainer scripts or a change to dpkg. You just criticized maintainer
scripts, so I would assume that they are not your favorite solution.
Furthermore, others have pointed out that essential packages need to work
before maintainer scripts are executed. This behavior is codified in
policy:
> "Since dpkg will not prevent upgrading of other packages while an essential
> package is in an unconfigured state, all essential packages must supply all
> of their core functionality even when unconfigured".
In other words, using maintainer scripts to create the symlinks that
enable the core functionality of these packages during configuration is a
no-go without a revision to policy and a change to dpkg (which might be
impossible). That means the symlinks would need to be included in the
package declaratively: but simply shipping them would break the existing
merged-usr installations. We've already established that un-merging and
then re-merging every installation isn't going to happen: so we'll need to
get the file references in place using a method that isn't shipping two
aliasing files and doesn't require maintainer scripts.
Now, shipping the file in /bin, and then eventually moving it to /usr/bin
and replacing it with a symlink as soon as you can would work, but that
isn't a solution. It means that we will always have packages that ship
files in /bin, because there is no migration path out of that, short of
completely redefining 'essential'. In thirty years, the bash package will
still contain this cludge. That is not a suitable long term solution, and
I think you agree.
Simply modifying dpkg to automatically produce symlinks from /bin to
/usr/bin at unpack time is not enough either: dpkg isn't necessarily the
tool doing the unpacking, and so other tools would need to be modified,
each one of them checking for a merged-usr and then accounting for it if
needed. This solution is actually viable: it would lead to a working
system, and not break the essential guarantee.
However...
Achieving this would require changing every tool that is responsible for
unpacking a Debian package. That isn't just dpkg and debootstrap: there
are many others. mmdebstrap and cdeboostrap come to mind. This approach
thus requires significant changes to at least four distinct tools. It
would also require at least two upgrade cycles before maintainers could
actually rely on the system being merged-usr: one cycle to get the dpkg
change out, and another to ensure that all packages have been changed to
ship their files in /usr. That is four years of waiting.
Of course, one could drop that to two years if you made the dpkg change a
little bit more aggressive. Since we already have dpkg creating
compatibility symlinks, why not have it also handle the file move? Simply
treat all files shipped to /{bin,sbin,lib} as actually being shipped to
/usr/{bin,sbin,lib}, and create symlinks accordingly. But that raises an
important question.
If we are willing to do that, why not just tweak dpkg to support merged-
usr-via-aliased-dirs? As far as I can tell, the problems with the layout
boil down to "we're letting packages treat the folders as separate, but in
the layout they aren't". Since we are already changing dpkg to make it
treat the folders as equivalent (which we need to do to avoid a long and
painful upgrade cycle), why not just save a few hundred symlinks and use
the aliased-dirs layout?
Thanks for making it through my castle of text,
Calum McConnell
signature.asc
Description: This is a digitally signed message part
