[lsb-discuss] Call for Topics - 2012-02-15 conference call

[Steve Langasek]

On Tue, Feb 14, 2012 at 03:06:44PM -0500, Robert Schweikert wrote:
> >>/usr get mounted in the initrd. Yes for people not using a
> >>distribution and no initrd things become a bit more cumbersome, but I
> >>am not certain this is a disqualification for the merge.

> >Not everybody wants to use an initrd. Are you suggesting is should be
> >mandatory?

> Nope. However, all distributions use an initrd

That cannot be assumed.  There is in particular an effort for the Ubuntu ARM
port to default to using no initramfs whatsoever, because all the modules it
needs for the rootfs are built-in.  (There are probably other distributions
that are initramfs-less by default that I just happen not to be familiar
with - embedded distributions in particular.)

However, the cases which are most likely to benefit from initramfs-less boot
(due to very slow disk reads from the firmware) are also unlikely to
configure /usr as a separate partition.

So I still think that merging /bin, /sbin, and /lib into /usr is wrong, but
I so far haven't actually found a use case not addressed by the "mount /usr
in initramfs" solution and am instead just left with a sense of general
unease about the whole thing.

> and those admins that do not use the distribution provided boot mechanism
> are sophisticated enough such that they can handle the migrated binaries
> or they can break the link between /bin and /usr/bin and add what they
> need to /bin.

No.  The FHS is intended to provide a *comprehensive* filesystem layout.
The answer must never be "if your system needs $foo, just disregard the
FHS's requirement for $bar".  Where this happens, it's a bug in the FHS that
should be fixed - we should absolutely not KNOWINGLY be adding such bugs!

> IMHO having the opportunity of a truly shared ro /usr outweigh the
> extra work people not using an initrd will have to do.

There's a logic error here in the justification for / -> /usr.  If you're
using a distribution, you have to contend with the distribution package
data, which is invariably stored under /var; and you almost always have to
deal with config file synchronization under /etc too.  These are far more
serious blockers for having a shared, ro /usr in an install of a
package-based distribution than /bin,/lib,/sbin are.

And OTOH, if you aren't using a distribution for your shared-ro /usr setup,
it hardly matters what the distributions do or don't do in support of this.

In either event, the FHS doesn't need to change at all to enable this
configuration.

>  However, a "modern" Linux system does not boot properly already if
> /usr is not either on the same file system as / or not mounted first
> thing, i.e. in the initrd.

Perhaps Fedora doesn't boot properly in these cases (nor SuSE?), but Ubuntu
has no problems making this work.  I know there are a few corner cases in
Debian that are currently buggy, but those could be addressed with little
trouble by installing a few libraries to /lib.

It's a separate question whether it's worth moving individual libraries
around vs. abandoning this split.

> >This now seems to be migrating to initrd
> >with an associated decrease in the visibility of what is happening. In
> >some cases, the initrd is needed, but in most cases, it isn't.

> I didn't want to debate the pros and cons of the move on this list,
> there have been plenty of debates about this already, and they are
> still ongoing. What I am after is a discussion on tomorrows call and
> a clarification of whether or not the move of binaries from / to
> /usr does or does not violate the current released FHS and LSB.

I don't see any reason that the LSB conference call should be the forum for
discussing this; that seems like a topic for the fhs-discuss mailing list?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20120214/3eb80721/attachment-0001.sig>