>>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
Received on Wed Dec 04 2019 - 21:02:31 UTC