Re: usrmerge -- plan B?
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
Reply to: