Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?

[Mark David Dumlao]

On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol <mikemol@×××××.com> wrote:
>> or the fact that some udev programs tend to
>> be located in /usr,
>
>
> That's either a bug with those programs, or a need for architectural
> improvements within udev. Both plausible answers.
>

The most obvious architectural improvement being: simply place udev
where all its dependencies are and all those bugs turn to nothing.
Which is what the udev guys did. And the part which seems to elude
everyone is: it isn't even a limitation of the program. It can still
be installed to /. Heck we could probably make a USE=root-prefix flag
for udev that installs it to / instead of /usr.

>
>>
>> or even just a solid detailed specification on the
>> precise criteria for inclusion into /.
>
>
> For anyone arguing that / and /usr should be separate, the answer to this is
> "that ought to be common sense."
>
> Since I'm not someone who knows all there is to know about the software and
> interactions thereof, the most I can say is:
>
> * / ought to contain all binaries, libraries and static data necessary for
> booting beyond the point where / is mounted, and any machine-specific
> binaries, libraries and static data.
> * /usr ought to contain all binaries, libraries and static data not
> necessary for its own mount.
>

I'm sure you mean well, as did most of the architects of the past, but
the reality is, this simplistic take on the problem misses out on some
fundamental issues. Yes, you mention later that the spec just doesn't
specify what happens in such and such case, and try to trivialize it
into saying people think that specs should "be able to do their
thinking for them". But unfortunately, specifying what happens is
exactly what specs are for!

However...

>>
>> Even the FHS is mum on all the
>> extra crap we randomly decide between / and /usr to land in.
>
>
> So fix it. FHS was a document written to say "we have a standard" that
> happened to map almost cleanly to all the implementations of the day. Kinda
> like how SQL mapped "almost cleanly" to the existing RDBMSs that existed
> when it was introduced. Such is how standards documents are born.
>

Don't forget that FHS is heavily an after-the-fact descriptive
document of what is happening in practice, with heavy "rationale"
sections describing what's going on in the wild. Before you can fix
FHS, you first have to fix the practice, then FHS can get amended to
reflect what's going on.

And the "we have a standard" part is effectively not true anymore, on
the matter of the / and /usr split. That is - what the specification
says should happen is not happening, on a massive scale, because it
turns out that it's not that trivial to determine which binaries go in
/ and which go in /usr. Now that doesn't translate to epic disasters
of biblical proportion, fire and brimstone, rivers and seas boiling,
dogs and cats living together, mass hysteria - because it's just a
collection of hard to pin down "essential" boot programs - but it does
translate to an unsustainable practice in distro development / package
management.

http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM

"""
Purpose:
The contents of the root filesystem must be adequate to boot, restore,
recover, and/or repair the system.

To boot a system, enough must be present on the root partition to
mount other filesystems. This includes utilities, configuration, boot
loader information, and other essential start-up data. /usr, /opt, and
/var are designed such that they may be located on other partitions or
filesystems.

To enable recovery and/or repair of a system, those utilities needed
by an experienced maintainer to diagnose and reconstruct a damaged
system must be present on the root filesystem.

To restore a system, those utilities needed to restore from system
backups (on floppy, tape, etc.) must be present on the root
filesystem.
"""

* some teasers:
[1] udev rules themselves being a case in point. I mean, do the
requisite binaries belong in /? For example, there's a virtualbox udev
rule in /usr that doesn't mount other filesystems or stop udev from
starting. However, given the right race conditions, udev will fail to
start the requisite script because /usr isn't mounted.
[2] fuse-based filesystems allow an administrator the crazy
possibility of, for example, demanding that /home be an ssh
connection. Should the ssh client belong in /? ftp? substitute any
arbitrary client program.
[3] a fuse-based filesystem depends on a local network service being
started. For example, someone writes a crazy fuse mysql browser that
also is coincidentally mounted at boot time. Should the mysqld service
belong in /? ldap? substitute any arbitrary server program.
[4] /root (which is why it's separated from /home) contains docs and
custom utilities used by root user for recovery. Unfortunately,
there's a lot of perl scripts there specifically for doing filesystem
checks / reports. Should perl be in in /? substitute any scripting
language.

The point is not whether _you_ can come up with an answer for _your_
own case. A _standard_ speaks for everyone that conforms to it. If it
doesn't, or it comes up with conflicting use cases as above, the spec
is broken. The fact that edge cases are appearing (and would all
disappear if / and /usr were merged) is a hint that something funny is
going on.
--
This email is:    [ ] actionable   [ ] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none