supporting merged-/usr-via-aliased-dirs in dpkg
Hi Guillem,
please Cc me in replies.
Disclaimer: I'm doing this on Freexian capacity.
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.
To that end, I looked through written material by you and identified the
following as relevant. Do you spot anything important missing?
https://wiki.debian.org/Teams/Dpkg/MergedUsr
Among other things, this wiki page identifies problems arising from the
aliasing layout. It seems fairly exhaustive to me and provides a starting
point as to which aspects may need changes.
https://lists.debian.org/debian-devel/2021/07/msg00196.html is an earlier and
partial summary of problems written by you earlier.
https://lists.debian.org/debian-devel/2020/02/msg00477.html establishes
nomenclature for merged-/usr, merged-/usr-via-aliased-dirs and
merged-/usr-via-moves-and-symlink-farms.
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.
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?
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.
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.
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.
I'm not sure whether we also need a --remove-alias <symlink> option. If we
don't, we can make --add-alias irreversible (much like uau's patch did).
Evidently, this simplifies a lot of things - not least lookups of canonicalized
paths.
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
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.
I've talked about this with Simon McVittie and Julian Andres Klode, both
of which considered this approach viable (up to colouring the shed).
Helmut
Reply to: