(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=m...@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