Quoting Laurent Bercot (2024-05-26 12:53:39) > If you are building a distribution aimed at supporting several kinds > of hardware, I suggest adding flexibility at the *source database* > level, and building the compiled database at system configuration time
If at all possible, do this. > (or, in extreme cases, at boot time, though I do not recommend that if > you can avoid it, since you lose the static bootability guarantee). I believe there is also a third approach which is sort of a middle-ground: all oneshots and longruns are compiled statically, but the contents of bundles are determined at boot time. Think of it by analogy to the Linux kernel: distros nowadays build every single module under the sun -- no matter how obscure -- but only a few ever get loaded. I believe that s6-rc-bundle is the tool used to edit the bundles: https://www.skarnet.org/software/s6-rc/s6-rc-bundle.html I haven't actually tried this myself, but perhaps it might help. Changing the contents of bundles seems like a much less-violent action to take at boot time, with fewer possible failure modes. If you go this route, there is a fork in the road. Assuming you're using s6-linux-init, - The easy route: in a perfect world you'd do this boot-time detection from within `rc.init`, before invoking `s6-rc start $DEFAULT_BUNDLE`. Unfortunately at that point you probably don't have anything mounted read-write (except /run), haven't started your hotplug daemon (e.g. mdevd), and haven't done a coldplug yet. So the easy route might not work. - The hard route: remember that s6-rc's locks are *not* reentrant! You will have to think very carefully about what locks are held with s6-rc-bundle is called, and whether or not to use its `-b` flag. Don't try to use s6-rc tools from within a oneshot. - a
