I suppose I must take a closer look at which assumptions are involved.
You tell s6-svscan that the absolute path to the s6-supervise *from the same package* is /command/s6-supervise. This is not true if you install more than one version of s6. You make /package and /command inseparable, when /package should not depend on /command.
Maybe I'll put a lobotomized /package dir in the initramfs, with dir containing symlinks to /command/ (Not all binaries of the hard-drive /command are copied to the initramfs, only those that are really needed.)
Yes, you can do that.
For example, for the execline package: am I right to assume that binaries must be accessible in /package/admin/execline/command/, and that this is the only requisite in order to be compatible with slashpackage, at least when statically compiled? If so, I can cook up a symlink based setup that will be easy to maintain and very lightweight...
Yes, that will work.
No, it won't get free, as I keep the initramfs as / all the time (hard drives are mounted under /slash)
I had such a setup for a long time (with an initrd, back then)... I had to write the horror that is s6-update-symlinks (formerly update-symlinks) to make it work. It did work, but was never satisfying. Then I realized I could just throw away the initrd, and was Enlightened. initrd, and now initramfs, are tools used by distributors that have to make very generic kernels and installation/boot procedures. And, like with dynamic linking, ntpd, and smartphones, everyone follows and uses it, even if simpler approaches may work just as well for them. Break free of those chains of complexity. They're only holding you back! ;)
My initramfs doubles as rescue system (of sorts, anyway)
If your / was read-only, you'd never need a rescue system :P -- Laurent
