Why /command ?

Why /command ?

[Steve Litt]

Hi all,

I'm writing a document on how to install runit on Devuan, with the hope
that some day it will lead to a Devuan package that makes sense and to
the best degree possible implements the goals of the software's author.

Most of it's pretty straightforward, but the runit install scripts
(package/upgrade to be specific) create /command right off the root,
and the runit docs suggest I create /package right off the root. These
are things that most distros would refuse to do.

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?

By the way, if the runit docs go well, I'll do the same thing with s6.

Thanks,

SteveT

Steve Litt 
June 2017 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: Why /command ?

[Kevin Berry]

[-- Attachment #1.1: Type: text/plain, Size: 1552 bytes --]

Steve,

Have you checked for the source package to runit-run?  You may find trouble
getting the Devuan devs to accept a slackpackage install, since it doesn't
meet the FHS.  runit-run is a package that used to exist in Debian (and
Ubuntu imported it until 12.04, I believe), that Gerrit made to fit in the
FHS.  Some other De(bi|vu)an -run packages still exist that work in a
similar manner.

On Sat, Jul 1, 2017 at 11:37 PM, Steve Litt <slitt@troubleshooters.com>
wrote:

> Hi all,
>
> I'm writing a document on how to install runit on Devuan, with the hope
> that some day it will lead to a Devuan package that makes sense and to
> the best degree possible implements the goals of the software's author.
>
> Most of it's pretty straightforward, but the runit install scripts
> (package/upgrade to be specific) create /command right off the root,
> and the runit docs suggest I create /package right off the root. These
> are things that most distros would refuse to do.
>
> 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?
>
> By the way, if the runit docs go well, I'll do the same thing with s6.
>
> Thanks,
>
> SteveT
>
> Steve Litt
> June 2017 featured book: The Key to Everyday Excellence
> http://www.troubleshooters.com/key
>



-- 
Kevin Berry

[-- Attachment #1.2: Type: text/html, Size: 2230 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: Why /command ?

[Andy Mender]

[-- Attachment #1.1: Type: text/plain, Size: 1386 bytes --]

Dear Steve,

I tinkered with runit on Devuan and Gentoo and managed to get some things
done with it in the past.
Here is the link to the docs I wrote for Devuan previously:
https://talk.devuan.org/t/runit-as-init-supervisor-for-devuan/487

Cheers,
Andy

On 2 July 2017 at 01:37, Steve Litt <slitt@troubleshooters.com> wrote:

> Hi all,
>
> I'm writing a document on how to install runit on Devuan, with the hope
> that some day it will lead to a Devuan package that makes sense and to
> the best degree possible implements the goals of the software's author.
>
> Most of it's pretty straightforward, but the runit install scripts
> (package/upgrade to be specific) create /command right off the root,
> and the runit docs suggest I create /package right off the root. These
> are things that most distros would refuse to do.
>
> 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?
>
> By the way, if the runit docs go well, I'll do the same thing with s6.
>
> Thanks,
>
> SteveT
>
> Steve Litt
> June 2017 featured book: The Key to Everyday Excellence
> http://www.troubleshooters.com/key
>

[-- Attachment #1.2: Type: text/html, Size: 2078 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: Why /command ?

[Laurent Bercot]

>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

_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng