レナート   Wunschkonzert, Ponyhof und Abenteuerspielplatz   ﻟﻴﻨﺎﺭﺕ

Thu, 26 Jan 2012

The Case for the /usr Merge

One of the features of Fedora 17 is the /usr merge, put forward by Harald Hoyer and Kay Sievers[1]. In the time since this feature has been proposed repetitive discussions took place all over the various Free Software communities, and usually the same questions were asked: what the reasons behind this feature were, and whether it makes sense to adopt the same scheme for distribution XYZ, too.

Especially in the Non-Fedora world it appears to be socially unacceptable to actually have a look at the Fedora feature page (where many of the questions are already brought up and answered) which is very unfortunate. To improve the situation I spent some time today to summarize the reasons for the /usr merge independently. I'd hence like to direct you to this new page I put up which tries to summarize the reasons for this, with an emphasis on the compatibility point of view:

The Case for the /usr Merge

Note that even though this page is in the systemd wiki, what it covers is mostly orthogonal to systemd. systemd supports both systems with a merged /usr and with a split /usr, and the /usr merge should be interesting for non-systemd distributions as well.

Primarily I put this together to have a nice place to point all those folks who continue to write me annoyed emails, even though I am actually not even working on all of this...

Enjoy the read!

Footnotes:

[1] And not actually by me, I am just a supportive spectator and am not doing any work on it. Unfortunately some tech press folks created the false impression I was behind this. But credit where credit is due, this is all Harald's and Kay's work.

posted at: 22:29 | path: /projects | permanent link to this entry | 16 comments


Posted by Anonymous at Fri Jan 27 02:31:08 2012
While I agree with almost everything you've said in this writeup (and I plan to point people at it rather than having to repeatedly re-explain it myself), do you really want to use "Solaris does it" as an argument?  Compatibility with Solaris matters very little to most Linux software, and almost all new software targets Linux first and Solaris second if at all.  The last time I saw an argument that Linux should do things like Solaris, it came from Jörg Schilling.

Posted by non7top at Fri Jan 27 03:39:06 2012
Myths #9 and #10 are not valid. They are perfectly supported outside fedora. If / is overfilled with crap in fedora it's just a problem of fedora, if separate /usr is broken in fedora it's just a problem of fedora. Both problems can be fixed easily. Good news is that there are still some sane distributions exist which do not follow fedora way in breaking things which work perfectly for ages.

Posted by Lennart at Fri Jan 27 03:51:01 2012
Anonymous: if it was our only argument, then yeah, we should be ashamed. But it's quite handy as a get-out-of-jail-free card for all those Unix fundamentalists who claim that this was un-unixy. Because, well, the most relevant commercial Unix actually did just this change already...

non7top: Well, that it's not only Fedora that is this "broken" you can see here:
https://plus.google.com/114669104565190507739/posts/TcMqLb6X9Nz
and here:
https://plus.google.com/104232583922197692623/posts/DnSgg6qzRmD
and here:
https://lwn.net/Articles/477507/
And now get off my lawn, will you?

Posted by Daniel at Fri Jan 27 11:56:17 2012
What happened to the proposed change of /usr/sbin -> /usr/bin as part of the /usr merge?
I remember reading it being proposed together and I don't see it anymore. IMHO it makes more sense then the merge since the separation there is completely arbitrary and there are plenty of things in (/usr)/bin that aren't by regular users and things in (/usr)/sbin which are usable by regular users...

Posted by Lennart at Fri Jan 27 14:11:36 2012
Daniel: that bit got delayed for one release and will be proposed for F18 again.

Posted by blk at Fri Jan 27 15:34:16 2012
While i will agree with some points, all in all it just doesn't seem worth the trouble.
It's been working for a quite good while and there don't seem trouble ahead for leaving it this way.
Fedora wants to change it, fine. Since /bin gets symlinked it won't really matter, now will it?

And for solaris people who care about linux compat, they'll have to do it the "linux-way" for quite some time anyway since stable distros aren't going to change this post-release.

cheers

Posted by Ulrik at Fri Jan 27 16:06:21 2012
Something for the FAQ: Which path to prefer? Should I always use /bin/ls or always /usr/bin/ls? The former is more practical, the latter is the real location.

Posted by mayem at Fri Jan 27 16:16:04 2012
answer: whatever comes first in your $PATH

ls -l /usr/bin/ls
ls: cannot access /usr/bin/ls: No such file or directory

Posted by Ulrik at Fri Jan 27 19:39:06 2012
Mayem: with a /bin -> /usr/bin symlink, your scenario won't happen.

Posted by Michael at Fri Jan 27 21:02:00 2012
The /usr merge is fantastic!
I hope sbin gets killed too (next release cycle).
Is the separation between lib and lib64 really necessary? (Some distributions make a symlink...)

Posted by Foo at Sat Jan 28 01:20:47 2012
Awesome!

As others have pointed out, while you are at it, maybe you should also merge bin and sbin, and symlink bin to /usr/arch/$arch/bin, and lib to /usr/arch/$arch/lib.

And also maybe move /usr/local to /local and make /tmp per-user.

Posted by Anonymous at Sat Jan 28 03:04:30 2012
Lennart: I agree that "Solaris does it" seems like a good argument to satisfy people who would otherwise consider /usr an olde UNIX tradition (as opposed to a historical artifact whose modern-day equivalent would be "I accidentally filled up the / partition, mount --bind /bin /home/bin").

Posted by Christopher at Sat Jan 28 17:10:36 2012
Orthogonal to the content itself, I've noticed a few English articles recently written by German speakers where they use "resp.", presumably where they'd use "bzw." in German.

This doesn't really work as a direct translation, and I don't recall ever seeing the short form "resp." in native English text.  A suitable replacement would be "and respectively".

Pedantic, perhaps, but there you go. :)

Posted by x3oo at Sun Jan 29 07:50:44 2012
hi lennart, darf ich mal unpassenderweise fragen, auf welcher platform der blog und die photo seiten basieren?

Posted by Anonymous at Mon Jan 30 14:19:06 2012
I don't want gcc and others in some esoteric directories as Solaris has/had.
I don't want to merge directories to fix GNU autohell just that each and every Distro is forced to fix that or die (read: patch, again.).
I am allowed to set $PATH as user. I expect my ls to be used in scripts and on cli if it's in ~/bin and that's before /bin in $PATH. Period.

Posted by LGB at Thu Feb 2 13:34:51 2012
My systems have root fs with about 50-100Mb. I except that system would boot just with that, if /usr is not mounted because of some problem, maintaince, etc. If there is this merge, you can't have that small root fs, which was nice in my opinion. However, I can see there are advantages too, for sure ... Hmmm.

Leave a Comment:

Your Name:


Your E-mail (optional):


Comment:


As a protection against comment spam, please type the following number into the field on the right:
Secret Number Image

Please note that this is neither a support forum nor a bug tracker! Support questions or bug reports posted here will be ignored and not responded to!


It should be obvious but in case it isn't: the opinions reflected here are my own. They are not the views of my employer, or Ronald McDonald, or anyone else.

Please note that I take the liberty to delete any comments posted here that I deem inappropriate, off-topic, or insulting. And I excercise this liberty quite agressively. So yes, if you comment here, I might censor you. If you don't want to be censored your are welcome to comment on your own blog instead.


Lennart Poettering <mzoybt (at) 0pointer (dot) net>
Syndicated on Planet GNOME, Planet Fedora, planet.freedesktop.org, Planet Debian Upstream. feed RSS 0.91, RSS 2.0
Archives: 2005, 2006, 2007, 2008, 2009, 2010, 2011

Valid XHTML 1.0 Strict!   Valid CSS!