Consider a fully s6-rc-managed machine. Such a machine would have an
'active' services database (the compiled database linked from s6-rc's
live state directory), and some place where service definitions would
be stored in source format. The active services DB would have been
initially created by running s6-rc-compile on all or part of these
definitions. I don't know what everyone else does, but the source
directory I give to s6-rc-compile is usually a temporary directory
with symbolic links to definitions stored somewhere else (in a sort of
services repository), that I delete afterwards.
After initial creation, with the possible exception of bundle
definitions, I imagine the active DB would be mostly static, and
expect changes to be generally small, like e.g. adding a couple of
services when there is a newly installed software package. Changes are
performed by running s6-rc-update on a new compiled DB, but
s6-rc-compile currently requires the full set of services in source
format to create one. So how would one manage this? Should one really
keep the source directories supplied to s6-rc-compile instead of
throwing them away, so they can be reused? Or construct a temporary
source directory from the services list returned by running s6-rc-db
on the live state directory, and then make the changes? Or...?
Also, depending on what method is used, there is the chance of missing
changes made in-place after the initial s6-rc-init invocation, like
using s6-rc-bundle on the live state directory to modify bundle
definitions (s6-rc-db's 'contents' subcommand could catch these), or
modifying longruns' env/ and data/ directories through the symlinks in
the scan directory (s6-rc-db cannot catch these).
All those are policy questions, which are voluntarily left out by the
s6-rc package itself. The answers to those, I think, will come with time
when "best practices" emerge from more s6-rc usage.
What I can do for now is say how I envisioned the tools to be used, and
what I expect package managers to do.
0. Remember that s6-rc-compile can take several source directories on
the command line, so you can have a "main" source directory and complete
it with "additional" ones, without having to mess with symlinks.
1. I think keeping the source directories at all times is important, if
the system is going to evolve. The only case I can see where you would
not keep the whole source directories is embedded devices with a static
service set: there, source directories are just development files and
are
stripped from the final image. But otherwise, yes, the source
directories
should be kept, and used as the authority on service contents, with
compiled directories being just a cache. One can even envision a system
where the compiled database is auto-regenerated at boot time if it
doesn't
match a certain hash (i.e. has been tampered with), for instance.
2. Distributions (or admins) that perform post-compilation changes to
the database (bundle modifications) should definitely log them under
their
own format so they can be replayed. Generally speaking, I added the
s6-rc-bundle tool because it was easy to make and added flexibility, but
it should not be used at the expense of reproducible builds. The
"official" way to add bundles should be to declare them in a source
directory and recompile the database; anything else is the admin's
responsibility.
3. env/ and data/ subdirectories are probably a trap as far as dynamic
service configuration is concerned. With s6-rc, s6 service directories
are
considered movable, and the contents of the live service directories
(which are typically in RAM) are not necessarily the contents of the
authoritative service directories that will be copied at the next
s6-rc-update or the next boot (i.e. those are in the compiled database,
on the disk). This is fully intentional: the goal is for package
managers to be able to upgrade package files (source directories
contents)
without messing with live services, and only update the live state at
the end, as atomically as possible, when the service database is
consistent again.
So, I think env/ and data/ should be used for configuration that is
mostly
static, i.e. that can wait until a database recompilation to be applied.
For configuration that needs to be applied immediately, it is best if
services store their config in a directory that is fully independent
from the service directory location, and access it via absolute paths -
typically under /etc.
Happy new year everyone,
--
Laurent
