Re: supporting merged-/usr-via-aliased-dirs in dpkg
Hi!
On Wed, 2022-11-02 at 23:35:23 +0100, Helmut Grohne wrote:
> I'm trying to figure out a way to make dpkg better support the aliasing
> approach chosen by the CTTE to implement merged /usr (aka
> merged-/usr-via-aliased-dirs). In order to avoid doing unnecessary work, I'd
> like to gather requirements first and hope you can help me with that part.
I'm doing a shallow reply over this, can expand further during the
weekend probably if necessary.
> https://lists.debian.org/20181223030614.GA8788@gaara.hadrons.org and
> https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/query-map-pathnames&id=b3f56ff6f3eaed17f534d544a3b6f8cc952e49c6
> are starting points towards solving the problems arising from aliasing.
Not really, the first lists things that are *not* proper solutions, the
branch includes a deadend which I discarded long time ago. Those two are at
least workarounds, and are definitely not on the path to proper solutions.
> This latter mail also mentions dpkg-statoverride as a problem area. I am
> wondering why it is missing from the wiki page. Do you mind me adding it
> there for completeness?
It's probably missing because I run out of steam, and making the page
more accurate has seemed pointless, TBH. But sure, go ahead.
> In reading all of the above, I had the impression that you spent much thought
> on explaining why merged-/usr-via-aliased-dirs is bad and how alternatives may
> look like. Unfortunately, this is the implementation strategy that we're
> heading for.
I've also mentioned what an hypothetical solution might be founded on.
On filesystem metadata tracking. But again I'm not even convinced this
can either solve the issues in a non-interface-breaking way either. :/
> Then we have this proof of concept patch by uau at https://0x0.st/oNFG.diff
> (and an earlier versions https://0x0.st/-7ev.diff and
> https://0x0.st/-7vq.diff). Evidently, this was discussed on IRC (presumably
> #debian-dpkg) and categorized as "conceptually broken". While I identified the
> lack of separation of policy and mechanism, you appear to take more issues with
> this approach. As I looked through all of this, I failed to identify what other
> issues you see. It sure is an irreversible operation on the dpkg database. Once
> performed however, a number of the problems arising from the aliasing
> disappear.
This would break interfaces, as it introduces change at a distance (as
packages can expect their paths to match what's shipped from what's on
the db, as packages are internally coherent).
Even not updating the db and remapping on the fly or outputting both
pathnames would be a breaking change.
Both of these approaches do not really solve the problem, they just shift
it elsewhere.
Old package shipping stuff in both aliased directories would also
still not be installable, even though their deps could be satisfied.
Not even the pathname filtering support affects the fsys database, for
example.
> Let me sketch a possibly new behaviour of dpkg. In the spirit of dpkg
> --add-architecture, I propose adding a new option dpkg --add-alias <symlink>
> <target> (e.g. dpkg --add-alias /lib /usr/lib). This invocation would record
> the alias in the dpkg database. Any time a dpkg tool operates on a path, it
> would canonicalize the path using known aliases. This includes dpkg-divert,
> dpkg-statoverride, triggers and update-alternatives.
This is equivalent (although perhaps slightly better as instead of a config
this is stored in the db so it can be used by commands that do not parse config
files) to the deadend approach from the above branch. This is trying to encode
filesystem knowledge that is supposed to be shipped in .deb into an option,
that can get out of sync, and still does not cover the change at a distance
issues.
Not to mention interactions with people relocating entire directories
via symlinks into other fsys points and similar, which is
unfortunately still a supported setup.
> Which problems would be fixed (+) or not (-) by this approach?
> - dpkg -S (possibly fixable, but maybe not worth it)
> - dpkg-deb -x
> + dpkg file overwrite/delete
> + dpkg-divert
> - dpkg-repack (only fixable, if the operation is reversible)
> + dpkg-statoverride
> + dpkg triggers
> - tar -x
> + update-alternatives
u-a does not interact with the dpkg fsys database.
> While this doesn't solve all problems, it does fix a significant fraction that
> is relevant to upgrading and maintainer scripts. That seems worth exploring to
> me. What do you think? Also note that once no package ships files in aliased
> directories, the dpkg-deb -x, dpkg-repack and tar -x issues will have no
> practical consequences anymore.
See above, I think this is the wrong way to go.
Thanks,
Guillem
Reply to: