> 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
Received on Thu May 15 2014 - 22:08:39 UTC