On 25/04/2015 21:38, Colin Booth wrote:
This actually brings up another question, is there any provision for
automatic bundling? If sshd requires sshd-log and a oneshot to create a
chroot directory does s6-compile also create a bundle to represent that
relationship or do we need to define those namings ourselves. This is
the inverse of my question about loggers being implicit dependencies of
services.

 I'll probably add an automatic bundling feature for a daemon and its
logger; however, a oneshot to create a chroot directory? That's too
specific. That's not even guaranteed portable :) (chroot isn't in Single
Unix.) If you want a change from the default daemon+logger configuration,
you'll have to manually set up your own bundle.


It depends on the persons setup. In my case it's a user-supplied
dependency since there's nothing intrisic to dnsmasq or hostapd that
reqires them to run together which I currently get around by polling for
dnsmasq's status from within the hostapd run script. All in all it's a
semantic difference between dependencies that are needed to start
(dependencies), and depenencies that are needed for correct functioning
but are not needed to run (orderings). The nice part is that while there
is a slim difference between the two, all the mechanisms for handling
dependencies can also handle orderings as long as the dependency tracker
handles user-supplied dependencies. Handling user supplied dependencies
also simplifies the system conceptually since people won't have to track
multiple types of requirements.

 What do you mean by user-supplied dependencies ? Every dependency is
basically user-supplied - in the case of a distro, the user will be the
packager, but s6-rc won't deduce dependencies from a piece of software
or anything: the source will be entirely made by people. So I don't
understand the distinction here.


One last thing and I'm not sure if this has been mentioned earlier, but
how easy is it to introspect the compiled form without using the
supplied tools? A binary dumper is probably good enough, but I'd hate to
be in a situation where the only way to debug a dependency ordering
issue that the compiler introduced is from within the confines of the
s6-rc-* ecosystem.

 The s6-rc tool includes switches to print resolved bundles and resolved
dependency graphs. I will make it evolve depending on what is actually
needed. What kind of functionality would you like to see ?
 (There is also a library to load the compiled form into memory, so writing
a specific binary dumper shouldn't be too hard.)

--
 Laurent

Reply via email to