From a Linux distribution perspective, there's also the question of if s6 can be
made a drop-in replacement for daemontools, since it does follow djb's naming
scheme. In gentoo, there are various packages that depend on
virtual/daemontools; for example, the nullmailer test suite uses ipcserver. From
a quick comparison of the documentation, it looks like s6 only adds options, and
remains compatible with the daemontools options.

Yes, and that was on purpose, but it's only true with the "official" API
and not with the internals. For instance, the supervise/status file
isn't compatible.

So would it be valid/acceptable for a distribution to create unprefixed symlinks
to the s6-* binaries? It looks like this would mostly only work for the subset
of the binaries that implement daemontools functionality; some others
(s6-setsid, s6-sudo) would have naming conflicts if they were not prefixed.

s6-setsid can be symlinked as pgrphack: same functionality, different
name. The same way that s6-log can be symlinked as multilog.

Then, with the symlinks, s6 could "provide" virtual/daemontools. Maybe this
would also help discoverability (the issue at hand). Maybe the inconsistency
would cause more harm than good, and the symlinks should be "for compatibility

s6 can provide at least surface compatibility with daemontools, yes. With
the symlinks, it can still be a drop-in replacement (unless there are
interface changes I haven't thought about).

daemontools replacement is easy. The real subject is compatibility with
runit, which is possible but not quite drop-in.


Reply via email to