[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On 05/07/2013 11:41 AM, Paul Tagliamonte wrote:

On Tue, May 07, 2013 at 05:36:41PM +0200, Marco d'Itri wrote:

On May 07, Paul Tagliamonte <paultag@debian.org> wrote:

No please. We are good about making sure they each mean something
important, and there's no good reason.

Not really nowadays: more and more things needed at boot time are
in /usr and there are no plans to "fix" them.

We also support setups that might need this split due to low
storage, such as arm devices.

"everything in /usr" actually means that supporting these devices
is much easier.

Not when you have a 500 meg internal storage that the firmware boots
off of, and using a multi-gig CF card to store the mega-awesome-app
you're using it for.

This seems to point to what I think may be a key question in the
ongoing/recurring '/usr'-related discussions, which I don't think I've
seen addressed in the iterations I've seen. If it has been addressed
well, please point me to past iterations which have so addressed it,
rather than rehashing the whole thing here just for my benefit.

The question, expressed in a number of different ways to provide a type
of "clarity by triangulation", is: Why does /usr exist in the first
place? Why was it created, way back in the day? What is its purpose,
what is it for?

My understanding, to the extent that I've had one, has always been that -
to oversimplify it a bit - / is for installs of things which are
system-essential, and /usr is for installs of things which are not. The
definition of "system-essential" can be debated, but again, my
understanding of it has been that it incorporates A: "boot-essential"
(things required for boot) plus B: "emergency tools" (things you want to
try to guarantee will be available in an emergency,
things-are-broken-and-we-have-to-fix-them scenario, such as might leave
you needing to rely on single-user mode).

The real-world scenario is obviously far more complicated than that -
dragging in definitions for what goes in /etc and /var and /home, and
further defining a distinction between /usr and /usr/local, and so
forth. But the basic concept seems simple enough as far as it goes.

Now, the next question is: does that distinction, that defining purpose
for the existence of /usr, still make sense in the modern world?

Almost everyone boots via an initrd nowadays AFAIK, which would seem to
more or less negate the advantages of keeping boot-essential things
separate that way - but "almost" still isn't everyone, and I don't know
whether we want to explicitly step away from support for non-initrd boot

The "emergency tools" side of it I'm less clear on. It's relatively
unimportant for cases where you have physical access to the system in
the emergency scenario, assuming you can take the machine down long
enough to boot into a rescue environment on removable storage (LiveCD or
USB drive, et cetera), but there may not be any analogous alternate
fallback for cases where you only have remote access to a machine, or
where taking the machine down that way may not be an option. There's
also the question of what scenarios this could actually help in, which
may be limited enough to make the entire thing negligible.

If the distinction does still make sense (which I personally think is
probably the case, though I don't have arguments to back it up at
present), then installing something "system-essential" under /usr is
Doing It Wrong, and we should not only not do it ourselves but push back
against upstream efforts to do it.

If the distinction does not still make sense, then we should explicitly
decide to reject it, and under that scenario moving to merge /usr with /
(in either direction) seems like a very sensible thing to do.

   The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger

Reply to: