Steve Litt schrob: > > From a Linux distribution perspective, there's also the question of > > if s6 can be made a drop-in replacement for daemontools, [...] > > In my opinion, 99% of all people currently using daemontools are highly > technically proficient and could easily either rename commands or > prepath to a directory containing prefixless symlinked synonyms. IMHO > if the distro does it, they'll find a way to screw it up. And even if > the distro does it right, it will screw that 1 in a million people > (like me) who occasionally use daemontools and s6 on the same box, > switching between them regularly. I find these claims to be rather unplausible, given my Debian experience. The Debian way would be creating a package "s6-daemontools" containing just the symlinks from foo to s6-foo and declaring the following package relationships: Depends: s6 Conflicts: daemontools Provides: daemontools That is, when s6-daemontools is installed: s6 must also be installed, daemontools must not be installed, but daemontools is treated as installed for dependency purposes. Then, you can choose to install s6 and daemontools together, getting the default naming for each. And I can install s6-daemontools and get tai64n/tai64nlocal binaries that produce correct timestamps despite my kernel clock being set to UTC. (That is, the ones from s6.) And every dependency on "daemontools" will be fulfilled, by exactly one of either djb's daemontools, or s6 plus the symlinks in s6-daemontools. See espeak-ng-espeak for a real package like that. This is hardly rocket science, and has been done for *decades* by now. Maybe non-Debian(-derived) distros are in the business of doing stupid sh*t, but then you should either switch to a sane distro or be building your own system. It's certainly no reason to refuse to consider the "s6 as daemontools" concept. Or to insist that people must setup the symlinks themselves. Onwards: Comparing the debian daemontools package with s6 gives: | $ dpkg -L daemontools | grep /usr/bin/ | sed -E 's_/usr/bin/_/usr/bin/s6-_' | xargs ls -1 | ls: cannot access '/usr/bin/s6-multilog': No such file or directory | ls: cannot access '/usr/bin/s6-pgrphack': No such file or directory | ls: cannot access '/usr/bin/s6-readproctitle': No such file or directory | ls: cannot access '/usr/bin/s6-svscanboot': No such file or directory | /usr/bin/s6-envdir | /usr/bin/s6-envuidgid | /usr/bin/s6-fghack | /usr/bin/s6-setlock | /usr/bin/s6-setuidgid | /usr/bin/s6-softlimit | /usr/bin/s6-supervise | /usr/bin/s6-svc | /usr/bin/s6-svok | /usr/bin/s6-svscan | /usr/bin/s6-svstat | /usr/bin/s6-tai64n | /usr/bin/s6-tai64nlocal | $ As Laurent said in the other mail: > s6-setsid can be symlinked as pgrphack [...] > s6-log can be symlinked as multilog. That leaves only readproctitle and svscanboot. The latter is just clearing env, setting $PATH and executing svscan /service 2>&1 | readproctitle service errors: ..... with 400 dots, according to the manpage. But I don't think there's an equivalent of readproctitle in s6. Plus, there remains the issue of non-compatible supervise directories. I don't think the above packaging scheme is valid if it would mean services (with their existing supervise dirs) fail to work because the supervise(8) implementation got switched from djb to s6 or vice versa. But in my quick testing they actually could re-use each other's supervise dir without tripping over the other implementation's artifacts.¹ Laurent, is that something that should work/you are willing to support? In that case, readproctitle would be the only remaining obstacle. regards, Jan ¹ They would not recognize each other's locking, however.