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 only".
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. -- Laurent
