[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: usrmerge -- plan B?

On Fri, Nov 23, 2018 at 04:32:17PM +0100, Guillem Jover wrote:

> Please, if we decide we want to do merged /usr, let's do it properly.

I'm toying with the idea of creating a merged-usr package indicating
'this system has merged /usr'. It could either fail to install with an
informational message on unmerged-usr systems, or if we're brave enough,
interactively or automatically convert the system (possibly utilizing
the usrmerge package.)

Then debhelper (or even dpkg-dev) could probe whether the build system
has merged /usr, and automatically add dependencies on merged-usr to
resulting binary packages, The dependency injection could be on either
an opt-out or an opt-in basis.

The opt-out way would be the more safe and conservative approach,
assuming everything built on merged /usr is broken on non-merged /usr
unless the maintainer indicates otherwise.

On the contrary, the opt-in approach would require that all problematic
packages (those that will not function fine when built on merged /usr
systems but installed on non-merged /usr ones) be identified and tagged
as needing this dependency. This obviously has a chance of missing
some of the issues.

Whether opt-out or opt-in, the transition in Debian could then be
controlled by monitoring dependencies on merged-usr, possibly playing
whack-a-mole rebuilding things that have gained this dependency in
maintainer uploads, or letting the gates open at some point and allowing
even core packages to gain this dependency (effectively forcing /usr
merge on all systems.)

All this would make the issues explicit and reflected in the package
dependency metadata, which seems to me like at least a step forward.
Niko Tyni   ntyni@debian.org

Reply to: