On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol <mike...@gmail.com> wrote: > 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. >
This is where you stumble. It's not a fix. It's a WONTFIX. It's a "make a lot of noise so that something else gets fixed because this is outside of our domain and we're not going to be responsible for it as it wasnt our bug in the first place". And that something else happens to be the / and /usr split conflicting with the user programs. If you give the squeaky wheel the grease - as in merge / and /usr - you apply the fix independently of udev, which was simply installed to the /usr prefix. THAT is a solution - one independent of udev and again, does not depend on initr*. You don't have to. >> >>> >>>> >>>> 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. Two things. First, I'm not saying that a spec should specify everything. I am saying, however, that there are specific cases that is within its domain to specify and that it should be specifying. And because those cases generate conflicts, the fact that they aren't is a bug. Second, going back to problem solving in general - just because you can put down in words what you think the problem is, doesn't mean you've mapped out an accurate or even consistent statement of the problem. There really are cases where it's not enough to just give general airy abstractions and rules of thumb to map out a problem, where it isn't obvious that you're running into edge cases until you really look at it deeply, and yes, the / and /usr split is one of them. >> 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. The most fundamental and relevant one for us Gentoo users is this: - how can /usr be sharable among different hosts if it depends on libraries in /? """ http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY Purpose /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. """ Many distros place fundamental libraries that many programs in /usr depend on in /lib. Especially bad for Gentoo - libraries in /lib may be recompiled as same-version variants if you want to change the USE flags, resulting in clients that don't synchronously recompile their own libraries in /lib to both silently and noisily fail. In other words, many programs in /usr in practice are functionally inseparable from the libraries in /, conflicting with the notion that they were properly shared in the first place. Compare this with the alternate spec that /usr contains both the programs and the libraries. In which case there is no possibility of the programs being out of sync with the libraries. From a maintainance perspective, this reduces the number of points of failure in upgrading the central NFS share. Please note, though, that the / vs /usr issue is a bigger thing after all than udev, and only happens to be a udev-centric discussion because it's one of the most obvious cases of the spec going awry. >> * 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. This is an interesting idea for a fix for the udev subproblem. However again note that the / and /usr split/merge is a bigger thing than the issues that just happen to manifest in udev. Perhaps right now they're giving up on it because they'd rather not waste time fixing a sub problem when fixing the / and /usr split fixes udev with less effort. > And rules files should perform sanity checking and feedback in the > form of "WTF? No, I can't do that yet. Wake me later." $ equery belongs udev/rules.d/|wc -l 36 On just my system, 36 different packages and god knows how many different upstreams / maintainers write to udev/rules.d. And that's Gentoo. How about Fedora. How about Red Hat. How about Debian, Ubuntu and god knows how many packages and distros that nobody can guarantee is going to use entirely new syntax. Face it - the udev guys are not going to be in control of whoever writes the rules. Yes, having wait / dependencies in udev might be a neat feature, but there's no guarantee they'll be implemented because they're not part of udev itself. On the other hand you can just edit the system so that the _default setting_ makes it unnecessary to specify dependencies for like 99.xx% of programs out there. > 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 Again, it's not enough to have just a passing understanding of the problem and talk airy abstractions about solutions. You really have to have an understanding of the problem space. systemd, for similar reasons to udev, is installed to /usr by default. This means that systemd won't even be runnable if /usr isn't available, so it won't even be possible to treat /usr as a service. So what you're saying makes no sense as far as typical systemd installations are involved. Now, if you installed systemd to / instead of to /usr, then yes you could create a /usr service which everything else would be dependent on. But you'd conspicuously make almost everything useful it does dependent on /usr, challenging the assumption that it should be separate in the first place. You would, for example, force 90-something percent of your unit files to have an extra dependency line that smells like it came from boilerplate kitchen, one of the things systemd was supposed to be designed to minimise. >> [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. It's misleading to think that /home being in ssh is an issue, because the point is that the purpose of the root filesystem is: "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." In other words, if /home is one of the "other filesystems" tools for mounting it should, according to FHS, be in the root filesystem. You're confusing that with the idea binaries are essential. And by the way, if you had emacs-daemon as an init service, it would depend on /home being mounted to be able to read the user's startup, or other similar things like that, so your system would not start up completely unless you had /home mounted. Now you say that it's alright, in this case, the sysad makes ssh available at /bin. But this undermines the primary FHS rationale: for binaries to be in _predictable_ locations for both the sysad AND the software packager. To implement this, then, as either the user / software packager / distro maintainer, I now have to do an intelligent check on /etc/fstab to determine that no filesystems are mounted on fuse. This demands, of course, a table of possible filesystem names and the corresponding client programs (currently not codified), plus that check to /etc/fstab. So the spec _fails to achieve its goal_ for systems where table of client-fuse mappings is not codified: practically all of them. Compare: if all executables were in /usr FHS would have no problem locating the client binaries, because they're all in the same place. > >> [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. Well I did say he was crazy ;) > > 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. > More or less same as above. Since the admin is now manually moving things around, the spec _fails to achieve its goal_. Compare: if all executables were in /usr FHS would have no problem locating the server binaries, because they're all in the same place. >> [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. /root is the home directory of the root user. If it's not available there, it defaults to the root directory (/). The point being the root user has its own storage that defaults to the root directory, independent of /home or whatnot. http://www.pathname.com/fhs/pub/fhs-2.3.html#FTN.AEN1037 One good reason why it's separated from /home is because the root user may download or store his own stuff there relevant to fixing that machine. For example, post-install notes are often placed in /root, which detail which packages were selected upon installation. Or while performing lengthy system maintainance, the sysad may write down their upgrade notes, or snip relevant tcpdumps, or what-have-you and store them in the /root directory while the /home directory is unavailable. It is very conceivable for the /root directory to contain perl scripts or whatever the sysad has downloaded in his adventures to grep through his logs and find out what the heck is going on in his system and/or repair it. Should perl be in / or /usr? Again compare: if all executables were in /usr FHS would have no problem locating perl. > 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. You have to think the individual cases through ;) > > 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. Yes, that should be. In fact I think that's the cleanest way to push through so far. Just add a USE=prefix-root to udev. -- This email is: [ ] actionable [ ] fyi [x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate [ ] soon [x] none
