>So I was wondering what the original intent was in having these two
>directories directly off the root? Is it so the init and supervision
>can proceed even before partition mounts are complete? Is there some
>other reason? Can anyone recommend setups that fulfill the reasons for
>the direct-off-root dirs without having direct-off-root dirs?
/package and /command are initially an idea from DJB. They were
introduced with daemontools.
The intent was to step away from FHS, which is a bad standard. You
can see the original issues that DJB had with FHS here:
http://cr.yp.to/slashpackage/studies.html
That was in 1997-1998, and 20 years later, things have not changed.
The FHS is still bad - arguably worse, because official-looking
documents have been written to make it look like the Standard™
without ever questioning its technical value: this is inertia and
laziness at work.
There are a few initiatives that had the courage to think about the
guarantees they want a file hierarchy to offer, and come up with
original solutions. Among them, for instance: DJB's slashpackage,
the GoboLinux distribution, and the Nix and Guix file hierarchies.
Each of those initiatives have their own advantages and their own
drawbacks, just like FHS. They make certain things possible or
more convenient, and certain other things impossible or less
convenient.
The main guarantee that slashpackage (and also typically Nix) wants
to offer that FHS does not, for instance, is fixed absolute paths for
executables. If you have a slashpackage installation, you know where
to find your runit binary: it's /package/admin/runit/command/runit.
if you only have FHS, there's always doubt: is it /bin/runit?
/sbin/runit?
/usr/bin/runit? This may not be a problem for runit, but it is a
problem for binaries you'd want in a shebang: execlineb, for instance.
Is it #!/bin/execlineb? #!/usr/bin/execlineb? Slashpackage gives
the answer: #!/package/admin/execline/command/execlineb. It's longer,
but prevents you from using horrors such as "#!/usr/bin/env execlineb",
which only displace the problem (there's no guarantee that env is
in /usr/bin, and in fact on some embedded devices it's in /bin).
There are other interesting things that slashpackage, or more
generally not-FHS, allows you to do that FHS does not. For one, the
ability to install side-by-side several versions of the same software
is pretty interesting to me: very useful for debugging. It also sounds
like something distributions' package managers should like. But FHS
makes it very difficult, if not impossible, and mainstream package
managers (including Alpine's apk!) are being held back by that.
I personally think that the guarantees offered by FHS were useful
at some point in time, but that we're long past this point and FHS
is mostly obsolete by now; that FHS is some legacy we have to carry
around for compatibility but that is preventing us from moving
forward instead of helping us. And distributions that refuse to move
an inch from FHS are the main problem here. They *are* the inertia,
and their unwillingness to question the validity of FHS stems out
of intellectual laziness. It was the case in 2000, it still is the
case today.
There are ways to nudge them towards adoption of better systems, but
it's a lot of effort and it's baby steps. The best software authors can
do is make their software completely configurable, adaptable to any
policy, and gently encourage better policies. s6 will install under
FHS, under slashpackage, under Nix and basically anything else.
runit, like daemontools, tries to enforce slashpackage - I wanted to
enforce slashpackage at some point, too, but unfortunately a convention
is only useful if everyone follows it, and nobody follows slashpackage.
And anyway it's not an author's job to enforce policy - that's a
distro's job, and if a distro's views conflicts with the author's,
it can simply avoid packaging the software, so authors have no leverage
at all on this front.
To answer Steve's last questions: there is no real way of getting
slashpackage's guarantees without following slashpackage, because
guaranteed absolute paths are only good if everyone can agree on their
location, and as far as slashpackage is concerned that ship has sailed.
However, there is still a way to get some of the additional benefits
of not-FHS: install a package in its own subdirectory - no matter where
it is - and make symlinks where required.
There's even a FHS place for packages that want to be installed
in their own directory: /opt. So if you want to install runit in a
FHS-approved location, you could use /opt/runit. You could use
/opt/runit/2.1.2, with a /opt/runit/current -> 2.1.2 symlink, or
/opt/runit-2.1.2 with a /opt/runit -> runit-2.1.2 symlink if you want
the "install several versions at the same time" benefit.
... but unfortunately, FHS specifies that /opt was made to install
software _that does not come from distributions_. So if a distribution
wants to be FHS-compliant, it cannot package software into /opt. That
is reserved for local administrators. Which was the very point of
/usr/local, but hey, redundancy is a good thing, right? Especially if
it constrains distribution policies even more!
So, I don't know. Distributions that want to follow FHS to the letter
will have real trouble evolving. What you can do is ask them if there's
a place they'd be ok with creating in order to store software that
wants to be installed in its own directory. They don't like /package
because they didn't come up with it themselves, but maybe they'll
accept something else if they get to choose the name. (Note that
/media is in the FHS - how's that for a useless direct-off-the-root
dir? Who mounts stuff in /media nowadays? and distros probably don't
have any issue with it because it's written in a Standard™.)
The Alpine Linux distribution is slowly coming to accept /pkg as
a place to install packages, similar to /opt but usable by the distro
and not by the local admin. Maybe you could convince other distros to
also use /pkg. Or /usr/pkg if they really can't stand creating
anything in / (because, hey, they already had to make room for /media,
so now there's no room anymore), but that would conflict with some
BSDs.
In any case, the distinction between root-filesystem and
not-root-filesystem is becoming less and less relevant. Most software
is installed on the root filesystem nowadays. Oh, and you can ignore
/command. It's just an alternative /bin for slashpackage, but /bin
does the job just as well.
--
Laurent
Received on Mon Jul 03 2017 - 13:25:19 UTC