"/usr unification" (or simply "usrmove") is the idea of moving the contents
, and related root-level directories into
their equivalents under /usr
. That this scheme is controversial
can be seen from that fact that, when LWN pointed
to a document describing the
motivations behind the move, a thread of well over 250 comments resulted.
One would think, from the volume of comments on LWN and elsewhere, that
this change is a threat to the very nature of Linux. Either that, or it
has inspired one of the biggest bikeshedding exercises in some time.
One of the "advantages" of running a Rawhide system is that one gets to try
out the new toys ahead of the crowd. Said toys also have a certain
tendency to arrive at random and inopportune times. In the case of the
/usr move, most Rawhide users got little or no warning before updates
simply failed to work. The Rawhide repository, it seems, had suddenly been
populated with packages requiring a system where the /usr move had
already been done. Actually causing this move to happen was left as an
exercise for the system administrator.
As it happens, this is one of the more controversial aspects of the
/usr move in the Fedora community. Fedora policy has always said
that using the yum tool to update an installation to a newer
release of the distribution is not supported; one is supposed to use a CD
or the preupgrade tool for that purpose. But, in reality, just
using yum tends to work; the prospect of it not working to get to
Fedora 17 has caused some grumpiness
in the Fedora user community. If this limitation remains in the
Fedora 17 release, expect to hear some complaints; users don't like to
have their ponies taken away, even if nobody had ever said they could have
a pony in the first place.
For Rawhide users, it is possible to move past the usrmove flag day by
set of instructions. The process involves editing the grub
configuration files, installing a special initramfs image, then rebooting
with a special option that causes the actual thrashing of the system to be
done from the initramfs before the real root is mounted. Your editor,
setting out along this path with a well backed-up system, was reminded of
doing the manual transition from the a.out to the ELF executable format on
a Slackware system many years ago. In both cases, one had the sense of
toying with fundamental forces with no guarantee of a non-catastrophic
In both cases, as it happens, things worked out just fine. Directories
like /bin, /lib, /lib64, and /sbin are
now symbolic links into /usr, and the system works just like it
always did. No programs or scripts needed to be changed, custom kernels
work as they always did, and so on.
That will almost certainly be most users' experience of this
transition - they will not even notice that it has happened. This is not a
particularly surprising result; the practice of moving files and leaving a
symbolic link in their place has a long history. Of course, somebody has
probably patented it anyway.
Of course, an equally successful result for all systems depends on the
Fedora developers creating a bombproof
automatic mechanism for carrying out this transition prior to the
Fedora 17 release. Hopefully something will have been learned from
the GRUB 2 mess, where the Fedora 16 upgrade left a lot of bricked
systems in its wake. If Fedora 17 creates similar messes on systems
that, perhaps, are not set up quite as the Fedora developers expect, a lot
of unhappiness will ensue.
As an aside, it is interesting to compare how Fedora is managing this
transition with Debian's multiarch transition. Fedora has forced
a flag day requiring the entire thing to happen at once; Debian, instead,
has carefully avoided flag days in favor of a carefully-planned
step-by-step change. One could argue that the Debian approach is better:
it lets the transition "just happen" through normal package updates without
the need for any special actions on the part of administrators or users.
On the other hand, the multiarch transition has been a multi-year process
and is still not complete; Fedora, instead, has pushed this change through
in a small number of months.
Now that Fedora has made this jump and seems to be past the turning-back
point, will other distributions follow suit? Some investigation suggests
that Fedora will not be alone in this change:
- There have been no official statements from Red Hat, naturally, but
it seems likely that, given how much effort has been put into this
change by Red Hat employees, RHEL7 will feature the unified directory
The RHEL clones, including Oracle's distribution and CentOS, will have
little choice but to incorporate this change.
- OpenSUSE has been discussing the idea for a while and seems to be
receptive to it. There does not appear to be an official statement
that openSUSE will make the /usr move, but there is a web page set up
to track progress in that direction.
- Debian has had a number of long discussion threads about usrmove; it
will not surprise longtime Debian watchers that there is a variety of
opinions on the issue. There is some concern about possibly breaking
systems with strange setups, though the most often cited case -
systems with /usr on a separate partition - has been thought
about and is relatively easy to support. In the end, it may come down
to making the change to keep life easier; as Marco d'Itri put it: "I am not really looking
forward to keep reverting these changes in my package, and since Red
Hat controls most Linux infrastructure now other packages will face
the same problem."
Of course, Debian has some time to think about the problem. Nobody
has suggested that usrmove could be added to the list of goals for the
upcoming "wheezy" release, so any transition, even in the unstable
tree, is likely to be at least a year away.
- Ubuntu has been relatively quiet about the idea; what has been posted
by Ubuntu developers suggests a lack of enthusiasm for the idea. But
if Debian makes the change, it could be hard for Ubuntu to retain the
current filesystem layout.
In short, it looks like, over time, the move toward keeping all binaries
and libraries in /usr will spread through most Linux
Given that most users will likely not even notice the change, it is natural
to wonder why the change is so controversial. Undoubtedly, some people
dislike significant changes to how traditional Linux systems have been laid
out. Possibly, some creatively-organized systems will not handle the
transition well, leading to problems that must be fixed. Conceivably, the
change strikes some people as useless churn with no real benefits - at
least for them. And, almost certainly, it is a bikeshed-type issue that is
easy to have an opinion on and complain about.
The truth of the matter is that it appears to be a reasonably
well-thought-out change driven by some plausible rationales. Filesystem
hierarchies are not set in stone; there are times when it makes sense to
clean things up. The usrmove operation yields a filesystem that is easier
to understand, easier to manage, and more consistent in its organization.
Having been through the transition, your editor thinks it is probably worth
to post comments)