On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao <madum...@gmail.com> wrote: > 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.
This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. > >> >>> >>> 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! Does the term "overspecification" mean anything to you? Specs cannot and should not specify every possible conceivable related thing. > > 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. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. > 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 /? Udev is a dispatcher. Actually, in substance, it's a piece of the kernel that resides in userland; it exists because it was decided back around the time of devfs that what devfs was doing is something that ought to be outside the kernel. In reality, it's effectively been a userland kernel-support process its entire life. What should probably happen is that udev should be fixed to defer hotplug events until a rules file is able to sucessfully handle it. And rules files should perform sanity checking and feedback in the form of "WTF? No, I can't do that yet. Wake me later." systemd does something interesting with its "After" clause; that makes perfect sense. And that's why I asked Canek why one couldn't write a systemd service file to treat /usr as a service, and make anything dependent on /usr's presence depend on the /usr "service". That would actually make _sense_. (Canek declined to opine, or even utilize his familiarity with the system to theorize how it could be done or what it would look like. I was disappointed; I was genuinely interested.) > 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. See above. > [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. System dependent binaries and libraries aren't commonly placed in /home. Your better argument would have been fuse-mounted /usr...in which case it would be the administrator's responsibility to ensure said arbitrary client program is present in /bin, and its libraries in /lib. > [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. I seriously cannot imagine anyone doing this except as a prank. The only similar case I can think of would have the db server on a separate machine. And if an administrator decides to do this, it's his responsibility to make sure mysqld is located in /bin, its libraries are in /lib...and he's got to find some place other than /var for his database! By this point, you've gone so far into reducto ad absurdum I honestly can't imagine anyone apart from someone who has absolutely _no_ idea what they're doing landing themselves in that situation. > [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. You quoted FHS. I'll quote it back to you: "/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems." /root is ridiculously out of the question. /home isn't defended by the spec, but it's commonly enough separated that it's difficult to imagine someone making that error twice. > > 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 use cases you described, per spec, are broken. The standard, as described, makes my answers to your use case descriptions virtually self-evident. > 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. What's funny is the gratuitous misreading of the spec that exists, the anticipation that it would explicitly state more than it does, the weak technical arguments (so far) in favor of merging / and /usr, and the dogmatic defense of the merge. With a system such as portage, it should be entirely possible (with few code changes) to configure installation targets (/ vs /usr) on a per-package basis, and have that trickle down the dependency chain. Certainly, many packages with broken build systems won't properly accept --prefix, but that's something that can (and should, and really, must eventually) be fixed. There's also the matter of stability while moving packages between /usr and /, but @preserved-rebuild and subslots should solve that. Now, binary distros? There are solutions to be had. They're more difficult. But most of the binary distros don't care, since they use initrd and update it automatically. -- :wq
