Re: Why /command ?

[Laurent Bercot]

1) /command can be put anywhere I/Devuan wants, or if I want to go to
  the trouble, removed completely.


 It can probably be removed completely, and binaries linked into /bin
instead. /command is nice to have on systems where you keep a FHS
installation and a slashpackage installation separate; but if you're
not going to follow slashpackage accurately and your package manager
is handling the symlinks anyway, /command has basically no value
over /bin.



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.


 Yes. Obviously, for low-level packages such as daemontools/runit/s6,
it is also important that they're on the root filesystem, but enforcing
presence on the root filesystem is not among the goals of /package.

/package can even be a symlink; the important thing in that convention
is that, for instance, /package/admin/runit/command/runit is a reliable
way of finding the current "runit" binary, no matter how many symlinks
you have to follow to get there.



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.


 Yes. (Preferrably not /etc/slashpackage since there would be entire
packages, including binaries, under /etc, which is not great. But
some people have tried stuff like /usr/slashpackage and been happy
with it.) It would still be not-slashpackage, so I'd advise changing
the name of the convention, but for people who follow the chosen
convention, it would give the same guarantees as /package.

 But again, a convention is only as good as the number of people who
follow it; it is probably easier to enforce in a distro than in the
wide world, but I'm concerned this would add to the idiosyncrasies of
distributions, if every one of them goes with its own convention. That
would widen the gap between distributions instead of bridging it. So,
if a distribution is willing to try a not-FHS way of installing
packages, I can't insist enough that they *communicate* with other
distributions and other people to try and settle on a general
convention, instead of doing their own thing.

 /pkg, which is what /opt would be if distributions could use it,
sounds rather good, and I would encourage distros to consider it.



4) djb's slashpackage technology still makes sense today, and should
  not be lightly tossed aside.


 Absolutely, and it's even more relevant today than it was in 1998.
The details of the locations (/package or anywhere else) are not
important; what is important is the benefits that a file hierarchy
convention can bring. And FHS is cutting it less and less, which
explains for instance the success of Nix; it would definitely be a
good thing for distros to start questioning the status quo and thinking
about what they really expect from a filesystem hierarchy, even if they
don't go yolo-full-slashpackage today.

--
 Laurent

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 

Re: Why /command ?

[Guillermo]

2017-07-01 20:37 GMT-03:00 Steve Litt:
>
> 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?

It has been mentioned in passing in other replies (and extensively in
other threads of this mailing list), but the answer is: Daniel J.
Bernstein's slashpackage convention.

* http://cr.yp.to/slashpackage/management.html
* http://cr.yp.to/slashpackage/versions.html

(And everything else in http://cr.yp.to/slashpackage, really)

> Can anyone recommend setups that fulfill the reasons for
> the direct-off-root dirs without having direct-off-root dirs?

At first sight I don't see anything wrong with Debian stretch's
packaging of runit. The list of files looks like it has all the needed
components, it respects the FHS layout, and depends only on the libc,
so probably can work on Devuan without modifications.

* https://packages.debian.org/stretch/runit
* https://packages.debian.org/stretch/amd64/runit/filelist

(Well, I hate /usr/bin and /usr/sbin for files that might be
components of an init system; if /usr is a separate filesystem it
needs an initramfs. But then again, binary-based distributions can't
probably boot without one anyway, unless the user compiles its own
kernel)

As the WWW page says, "complete init replacement needs to be done by hand":

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861536

Maybe you could help the Devuan project by trying document how to do
*that*. Package runit-init seems to have been dropped, and I can't
find its list of files in Debian's WWW package database. But judging
by what the bug report says, it was broken indeed (messages #10 and
#39 to me are the ones that more clearly explain why).

G.

Re: Why /command ?

[Kevin Berry]

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 
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

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