Hi Stephan,

# Disclaimer: / and /usr live on the same partition on my systems.
# Heads up: I just might change that ... back to what I used to do.

Stephan Seitz writes:

> Maintainers are encouraged to install everything in /usr because it must
> be available in early boot.

Call me dumb but I totally, completely and utterly fail to understand
why "Maintainers are *encouraged* to install everything in /usr".

# Emphasis added.

I just don't get what benefits

  for d in bin sbin lib; do
    mv /$d /usr/$d
    rmdir /$d
    ln -s /usr/$d /$d    # to avoid major mayhem
  done

will bring *me*. For maintainers, the only benefit I can think of is
removal of the need to think where something should go (and addressing
any fall-out of that should dependencies not be on the same partition).

For the record, /usr (whether on a *separate* partition or not) just
happens to be available in "early boot" because keeping it out was
deemed undoable, i.e. "requires more effort than the Debian maintainers
are willing to spend".

# I don't blame them for that, it's just that even though it might make
# economic sense, it is not a technologically or organizationally sound
# justification. I've been trying to point out that putting the system
# critical and non-critical stuff in different "drawers" makes sense in
# terms of organization. So has Didier.
# Insisting on putting these "drawers" in different "chests" (often for
# rather good reasons as Rick has tried to show) is actually why things
# get complicated.

> That’s why the usrmerge is only the logical next step. If you can’t live
> without /usr, you can put everything in it. Why should you waste your
> precious resources? There are enough other problems.

Fact: You can't live without /.
Hence, you can put everything in it.
Let's move /usr/{bin,sbin,lib} to /{bin,sbin,lib}, yeah!
Q: Why would you waste your precious resources moving stuff around?
A: Because needed stuff is on a different partition.
Solution: Disallow the different partition.
Objection: But the different partition makes it easy to impose
restrictions (think ro/nodev/nosuid) or tune performance (think
noatime).
Q: Isn't there some filesystem type that supports settings at a more
granular level than the device? Like directory or per file?
A: Eh ... Don't know. Haven't checked ...
Solution: Go fish!

# I haven't gone fishing yet but a vague recollection of Roger's post
# where he mentioned ZFS seemed promising ...

> With the many features an application can have today you will have a
> hard time finding and moving all the stuff [from /usr to /]. And then
> people would complain that their / doesn’t have enough space…

Tell them to increase the size of the partition that holds '/'.
Tell them to nuke the partition that holds '/usr'.
Make a usr-merge package that actually merges the partition that holds
the '/usr' file system tree with the partition that holds '/'.

Okay, so the three suggestions immediately above are tongue-in-cheek.
My main "stumbling block" is really about the (near) orthogonality of
filesystem tree organization and how that is mapped onto partitions.

If / and /usr are on a single partition, what is the benefit of moving
the contents of /bin, /lib and /sbin to their /usr counterparts? What
are the drawbacks?

If / and /usr are on different partions, what is the benefit of moving
the contents of /bin, /lib and /sbin to their /usr counterparts? What
are the drawbacks?

@KatolaZ Thanks for making the usr-merge an option in the installer.
         Even more thanks for making the default *not* merged because
         system-critical and system-non-critical really should be kept
         in different "drawers", IMNSHO.

Hope this helps, but somewhat afraid it won't :-/
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join