My future work relies more and more on daemons listening to UNIX domain sockets to provide machine-wide services, with access control and configuration via the uid and gid of the client. Usually that's not a problem: I can make those daemons depend on s6-networking, which provides the exact tools and libraries to make that easy. But among the daemons I'm considering, there's a fd-holding daemon, and its natural place is in the s6 package.
I cannot make it rely on s6-networking, since s6-networking depends on s6. Those two packages are getting interconnected, so some reordering will have to happen, and I'm wondering what the best course of action is. Entirely merging s6-networking with s6 is out of the question. The TCP part of s6-networking depends on s6-dns, and there's no way I'm making s6 depend on s6-dns. Cutting the libs6net and UNIX domain sockets part out of s6-networking and merging them into s6 sounds like the sensible thing to do, but it's kind of silly to have functionality for one type of socket in one package and the exact same functionality for the other type of socket in another package. I'm still leaning towards that approach, since UNIX domain sockets are not really "networking", more like "sysadmin stuff", but I wanted to hear opinions before proceeding. What do you guys think of the skarnet.org packages granularity ? Is it too fine ? too coarse ? Should I try and merge more functionality into a single package, or spread the functionality as much as makes sense ? What do you think the correct approach is for a daemon that I want in s6 but that would depend on parts of s6-networking ? -- Laurent
