Re: Merging / and /usr (was: jessie release goals)

[Helmut Grohne <helmut@subdivi.de>]

On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote:
> Fedora updates are different. (And so are Ubuntu updates, if one considers
> that it's possible to provide fixup scripts to update-manager pre-upgrade.)
> As long as we're supporting upgrades through plain apt, that's going to
> be hard. Especially if you have non-distro packages installed that need
> to be migrated as well, with the tracking information updated.

Maybe the issue here shouldn't be changing the default. After all there
is a quite vocal opposition to such a step. I fail to see consensus in
the recent mails without even contributing a personal opinion here.

So really what does it take to e.g. move /bin and stuff to /usr? Did
anyone try that? Where is that documented? What problems did occur?

### Analysis

I didn't do too much research on previous research, but just tried it.
As far as I understood from the discussion, the idea is to move
/{lib,lib64,bin,sbin} to the corresponding /usr location and turn them
into symbolic links. That doesn't sound too hard to do in a chroot. So
what goes wrong when doing this?

First of all there is /bin/touch and /usr/bin/touch from coreutils. The
latter is a symbolic link to the former. Same issue for /bin/which. So
before doing this merge, coreutils would have to change in some way.
Looking further there are things like less, acl, and cryptsetup all of
which provide similar symbolic links.

Are there "real" issues? Like actual files conflicting? This can
probably be answered using project-b, but I currently have no access to
that one, so I just used the database backing dedup.debian.net. Some
clever SQL needed here... [15 minutes later]

SELECT a.filename, a.package, (SELECT b.package FROM content AS b WHERE
b.filename = "." || substr(a.filename, 6)) FROM content AS a WHERE
substr(a.filename, 0, 7) = "./usr/" AND (SELECT c.id FROM content AS c
WHERE c.filename = "." || substr(a.filename, 6)) IS NOT NULL;

You were interested in the actual data? Quite short:
./usr/bin/openvt|console-tools|kbd
./usr/bin/dumpkeys|console-tools|kbd
./usr/bin/unicode_start|console-tools|kbd
./usr/bin/chvt|console-tools|kbd
./usr/bin/kbd_mode|console-tools|kbd
./usr/bin/setfont|kbd-compat|kbd
./usr/bin/git-ftp|git-ftp|git-ftp
./usr/sbin/syslogd|inetutils-syslogd|sysklogd
./usr/sbin/mkfs.lustre|lustre-utils|lustre-utils

Now console-tools and kbd are in conflict, so we don't care about that
one. git-ftp should be deduplicated the others likely need some deeper
look. All in all this looks fixable for a /usr merge.

So back to practical problems. How does apt cope with this situation?
Installing a random package (e.g. debsums) just works.

Talking about debsums. Did we break it? No debsums --all --silent is
happy.

### Conclusion

My conclusion for now is that just using a merged /usr in this way
appears to be possible. So instead of asking "should Debian do the /usr
merge", may I propose the question "should Debian support the /usr
merge"?

This actually makes up a possible release goal, because it is measurable
(just set up a system with merged /usr and see what breaks) and it
affects a number of packages (those compatibility symbolic links will
have to go). In addition this will likely require a change in the policy
(turning /bin/foo /usr/bin/foo file conflicts into a policy violation)
and it will need the work done by Roger Leigh (and others?) to support
mounting /usr in the initramfs.

I suggest to defer a decision on merging /usr by default until after the
release of jessie. The dependency based boot has similarly taken a
release for preparing the feature and then releasing it.

For those interested in my opinion: I don't consider myself a proponent
of the /usr merge, because the current way of doing things works for me.
On the other hand I do not see why Debian should not support that setup
if the cost is not too high and those interested are doing the work.

Helmut