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.ga8...@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
