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
Received on Thu Jan 15 2015 - 02:31:29 UTC