On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol <mike...@gmail.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
