Merged /usr - supported in stretch?
(everything below is AFAIK and IMHO, please correct any mistakes)
(Andreas added due to piuparts, see 4.)
0. Introduction
Merged /usr wiki page:
https://wiki.debian.org/UsrMerge
Merged /usr does not seem to be ready for a stable release right now.
The rationale used when the severity of #810158 was downgraded
to non-RC was:
Merged /usr is no more the default since debootstrap 1.0.87,
so the package is installable on new systems.
Not limited to this bug, my general impression of the current state of
merged /usr is that it mostly works - but it is not yet in a state that
it should be used by normal users of Debian stable on production systems.
There is no involvement or strong personal preference from me either way.
1. Required decision
A decision is required whether merged /usr should
a) be a properly supported and tested feature - including that
problems only visible with merged /usr are considered RC, or
b) the usrmerge package gets dropped from stretch
and support in debootstrap gets marked as experimental feature
The Release Team does have the powers to make bugs RC and remove
packages from stretch.
2. Getting merged /usr
There are two ways for getting merged /usr:
a) at installation time (debootstrap --merged-usr), or
b) installing the usrmerge package does an irreversible conversion
of an existing system
The usrmerge package contains versioned Conflicts on pre-stretch
packages, but the unversioned Conflicts on packages that are still
broken in stretch won't work in scenarios like:
apt-get install usrmerge
apt-get remove usrmerge
apt-get install ksh
3. Known bugs in stretch
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=md@linux.it&tag=usrmerge
yp-tools (no bug report?)
What is the status of "dpkg -S" with merged /usr ?
Any other known issues?
4. Automated testing
I do not know what kind of automated testing has already been done,
but there are at least 4 areas where piuparts might be able to find
problems with merged /usr:
a) testing that all packages in stretch can be installed and uninstalled
b) automated testing that there are no problems caused by /bin/foo and
/usr/bin/foo shipped in different packages
c) testing that the Conflicts of usrmerge cover all packages in jessie
that must be upgraded when installing the usrmerge package
d) searching for packages in previous releases that are no longer in
stretch and that break usrmerge, to have them added to the usrmerge
Conflicts
It would be beneficial for users upgrading to stretch if someone would
cover such issues with piuparts testing.
5. Real-life testing coverage
After reading the wiki page I still don't understand what actual benefit
merged /usr brings that could make me recommend it to a user.
Installing the usrmerge package is optional.
Since debootstrap 1.0.87 new installation are no longer using merged
/usr (see #844221).
The result is that only a small minority of current stretch users are
using merged /usr, lowering the probability of finding runtime breakages
before the release.
Thanks
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: