Re: usrmerge -- plan B?
Hi!
On Mon, 2018-12-03 at 18:22:03 -0800, Russ Allbery wrote:
> Guillem Jover <guillem@debian.org> writes:
> > The current merged-/usr deployment (via usrmerge or the bootstrapping
> > symlink generation before unpack) is a major hack, and bypasses the dpkg
> > understanding of the filesystem, it breaks dpkg-query, and while we
> > could workaround the breakage there, it's still the wrong way to go
> > around this.
>
> Does this imply that you're considering adding support for merging /usr
> *properly* directly inside dpkg, with all the correct updates to dpkg's
> metadata?
Above I was talking mostly about workarounds, such as the one I
mentioned earlier in the thread, which I've got as a draft patch
for dpkg-query to try to fix #858331:
<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/log/?h=pu/query-map-pathnames>
which mostly let's dpkg-query know about the aliasing in the filesystem.
This will still leave out dpkg-divert, dpkg-statoverride, dpkg-trigger,
and update-alternatives. This will also leave out any other software
that uses filesystem paths as keys in their databases.
Some of these other commands will just fail to find the files requested,
because they are not the canonical ones. On a merged-/usr-via-symlinks
u-a in particular can be told to make a mess if called like this f.ex.:
$ update-alternatives --install /bin/iface iface-a /usr/bin/impl-x 100
$ update-alternatives --install /usr/bin/iface iface-b /usr/bin/impl-z 200
What you are proposing above would be to do the magical mapping from
the canonical location found in the .deb into the new location on the
filesystem. I don't think this is a generally applicable solution.
Of the top of my head I can think of two potential ways to solve this:
* Relocatable packages [R], where dpkg would do some kind of global
diversion on specific pathnames.
This would require support from the package itself, at least to
denote that it supports being relocated. This might also require
major patching on the upstream side in case it does not. And if we
have to do either, we might as well have modified the canonical
paths in the package instead, which would be way less work.
This is still a somewhat interesting theoretical idea, though.
[R] The mythical dpkg 2.0 spec already talks about this in its
appendix G, <https://www.dpkg.org/doc/specs/dpkg2.pdf>.
* A variation on relocatable packages, but in addition automatically
inject the aliased paths into the filesystem and database as if
they had come from the package, for backwards compatibility, iff
they are not already present in the package or the database.
This would also require each injected pathname to be tracked
specifically, so that something like dpkg-repack can do its magic.
This would also have the potential to file conflict with random
stuff in case other packages provide those paths, and might be
difficult to check centrally, as the generation of those paths
would be local.
Both of these solutions would at no point convert the /bin, /sbin and
/lib directories into symlinks, I think doing that from within dpkg
would be maddness TBH.
Both would need the dpkg interfaces to be augmented in some way to be
able to tell what are the canonical paths for a file, and in the
second variant, which have been magically injected.
As generalized solutions to the aliasing problem it would mean that
local admins would be able to map files anywhere, which would imply
that the query results for (at least) many dpkg-related things could
vary wildly depending on the system, even when using the exact same
distribution baseline.
So I do not see how the above can be considered proper either in any
way. :)
> Because that would be an awesome way to fully support this.
While I think these are theoretically interesting solutions, they look
to me like huge can of worms, with very problematic consequences on
the global filesystem namespace we use as a shared interface. They
also imply to permanently suffer the aliasing problems.
To me it's always been very clear the only *proper* way to deploy
merged-/usr, is to do the changes to the canonical pathnames on
each relevant package. Even adding compat symlinks, means that dpkg
would know about them, and they'd be temporary anyway for the most
part until any remaining user has been made path relative or its
absolute path changed.
But the way this specific deployment plan has been pushed forward
has been extremely frustrating. There's been continued warnings about
the problems ahead, and they have been consistently ignored or
downplayed:
- the original dpkg-shlibdeps problems was known way ahead of the
initial debootstrap switch.
- the problem with misbuilds was also obvious and mentioned at least
on that same dpkg-shlibdeps bug report.
- the dpkg-query issue (and the aliasing problem in general) has
been also known for a while now.
And still the debootstrap default was switched again, when that
deployment method is an irreversible switch, which makes it really
a terrible default.
In the future whenever needing to install a new Debian system w/o this
hack the only easy recourse is to start from stretch and upgrade from
there. :/ I know I'm going to do locally anything at hand to avoid
the broken-by-design merged-/usr-via-symlinks on systems I manage.
At the same time, as I've also mentioned before, I'm happy to switch
the canonical path for packages that I maintain, whenever the project
comes back from this fool's errand… and decides to do the transition
properly. :)
Thanks,
Guillem
Reply to: