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
