On Mon, 03 Jul 2017 13:25:19 +0000
"Laurent Bercot" <ska-supervision_at_skarnet.org> wrote:
> >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
>
Thanks Laurent!
You gave me tons of info. Based on your info, the following three
assertions appear to be true. Could you please verify that each is
true?
1) /command can be put anywhere I/Devuan wants, or if I want to go to
the trouble, removed completely.
2) The reason /package is directly off the root has more to do with
just having a shorter reliable absolute path to an executable and
less to do with being on the root partition, which is mounted first.
3) If an individual distro decided to move their /package to a
different location, let's say /etc/slashpackage, and widely
publicized that fact and all their packagers respected
the /etc/slashpackage (for instance) location in all scripts, then
*for that one distro*, file locations would be just as determinant
as if djb's /package location was used.
4) djb's slashpackage technology still makes sense today, and should
not be lightly tossed aside.
Are the preceding four statements true?
Thanks,
SteveT
Steve Litt
June 2017 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
Received on Mon Jul 03 2017 - 18:34:49 UTC