Hi! On Wed, 2018-11-21 at 10:23:46 +0100, Adam Borowski wrote: > with less confidence: > • making usrmerge Essential (large amount of effort, known issues)
Oh dear, no, please! First off, as I've said in the past, I have no problem whatsoever with the concept, I think it brings both advantages (cleans up the FHS, makes some things easier, etc) and disadvantages (makes Debian perhaps a worse development environment for upstreams that want to target other systems, easier to miss pathnames that should not be under /usr leaking over, or a proper conversion making it not possible to keep unmerged /usr for those that would prefer that, for whatever reason, etc). As a proof-of-concept to make it possible to test the thing, to unearth bugs, as a quick way to deploy on throwaway containers, or even as a pragmatic way to switch ones system if there's a need for that no matter what, right now, the usrmerge package is great. But I do have a very big problem with us even considering using it as a way to deploy this change as part of our standard installation or upgrade. This is a hack, it's subverting the dpkg view of the world, and while this is intended to be supported somehow from dpkg PoV, I consider that to be on best-effort basis. For example I still have not merged the branch [Q] to make dpkg-query cope with the symlink stuff, as I was waiting for some feedback, and it still has some conceptual problems. Making usrmerge Essential is the "we cannot be bothered to do a proper transition and move things to their proper place" kind of plan. :( [Q] <https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=pu/query-map-pathnames> Please, if we decide we want to do merged /usr, let's do it properly. I'm still quite appalled that debootstrap has been change *again* (after it got reverted for stretch) to default to use this method for new installations… Thanks, Guillem
