>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
Received on Tue Jul 04 2017 - 00:22:46 UTC