On Wed, May 08, 2013 at 09:12:12AM -0400, The Wanderer wrote:
> 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 <paul...@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 initial problem was that the harddisk was too small. So you had to
split things up into 2 harddisks somewhere. / was the first disk, /usr
the second. We have long since past this problem.
Except it is comming back. With embedded systems that boot from a
"small" flash that contains / and then have /usr on a non-bootable
drive.
But those systems can put an initrd on flash to boot. I'm not aware of
any situation where an initrd can't be used (can't, not don't want to).
For Debian the problem has become that / must contain everything
needed to be able to mount /usr. And that includes such odd cases as
/usr on NFS over wlan and a million other permutations of any possible
way to hide /usr somewhere.
The problem in recent years has been twofold:
1) some people have become more creative and used new things to put /usr
on. Like iscsi or nfs over wlan. So more tools are needed in / to make
this possible.
2) most people don't have a seperate /usr or /usr on the same medium
as / and upstreams have been ignorant or neglient about ensuring the
right things end up in / and only things from / are used before
mounting /usr. The less people have a seperate (and complicated) /usr
the less this is tested and more bit-rot creaps in.
We have reached a point where other distributions have given up and
upstreams are saying they don't care for a seperate /usr anymore.
> 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
> configurations.
>
> 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.
On most (numerically) systems you have a bootloader that lets you
choose what to boot and it is trivial to add an emergency initrd with
all the repair tools you would ever want.
That is actualy much better than using / for emergencies since then /
will not be mounted and can be safely repaired too.
> 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 distinction does still make sense for every individual case. But
collectively installing everything anyone could ever need in / becomes
larger every day, harder to maintain and less supported by upstreams
(making it even more harder to maintain).
Compare that to the required effort to mount /usr from initrd.
The argument is not that there are no reasons for the / and /usr
split. But instead that the cost of the / and /usr split is higher and
has more bugs than simply working around it.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130509101122.GC31432@frosties
