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.
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.
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'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.
[dpkg-statoverride]
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.
[dpkg --add-alias proposal]
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.
u-a does not interact with the dpkg fsys database.
See above, I think this is the wrong way to go.
From my point of view, the most important property is finding a way to actually move files from / to /usr in a reasonably safe way. I thinkthis is important, because most of the aliasing problems are only
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 36:10:10 |
Calls: | 6,707 |
Files: | 12,239 |
Messages: | 5,353,434 |