>Hey Laurent,
>
>I am suggesting something like a [ -t ${TARGETDIR} ] option for the s6-linux-init program.
>s6-linux-init shall then copy the run-image hierarchy to ${TARGETDIR}
>and run s6-svscan on ${TARGETDIR}/service.
It would be doable, but I'm going to be frank with you, adding that
kind
of dynamism is 1. super annoying to code (because the string appears
*everywhere* and it's much easier to use when it's a constant than when
it's a variable), and 2. a footgun in most cases.
s6-linux-init-maker isn't something you want to run often. You want to
run it once, maybe edit the scripts it created, and then never touch it
again. You only have one /sbin/init, every time you update it you need
to make your rootfs read-write, you need to use the right tool or voodoo
incantation to update it safely (hint: ln -nsf is not safe), and the
less you're playing with the Powers of Creation, the better.
I made a concession to flexibility because I figured some people would
definitely not like /run/service. That's the --scandir configure option.
If you have a fixed policy, --scandir=${TARGETDIR}/service will do what
you want. If you have several policies you want to be able to swap to at
any time, I would suggest you keep a /run/service link to your current
policy, so stock s6-l-i would always work for you.
Or you could even have several sets of s6-l-i programs compiled
differently, one per policy. It would be a bit wasteful, but that's how
reluctant I am to make the scandir dynamically configurable.
--
Laurent
Received on Tue Mar 11 2025 - 02:00:48 CET