On Thu, Apr 14, 2011 at 05:31:35PM +0200, Lennart Poettering wrote:
On Thu, 14.04.11 16:35, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 15:48:09 Lennart Poettering wrote:
On Thu, 14.04.11 14:51, Michal Hlavinka (mhlavink@redhat.com) wrote:
On Thursday, April 14, 2011 13:26:02 Michal Schmidt wrote:
On 04/14/2011 11:14 AM, Michal Hlavinka wrote:
d) split it to more service files and make dependency there
this would be incompatible change in configuration and hard to do,
Hard maybe, but solvable. Incompatibility happens from time to time. That's what release notes are for.
Upstream has their cross-distribution packaging "guidelines" / effort / ... (I can't find the proper description.) Making configuration work different way then on other systems won't make anyone happy. If there is a way to keep current configuration working, then it's the way it will be done. Option c) would work, I'm just looking for another possibility to make it work the same way but also more systemd-like way.
I presume their guidelines just cover SysV-style bootups?
It's not only about SysV, but also says something like: when user starts nut, it should start exactly those services that are needed based on /etc/sysconfig/nut MODE=? option
/etc/sysconfig/xxx is mostly a Fedora/Red Hat idiom. I am pretty sure the Debian version of the boot scripts do not honour this request.
Debian has mostly identical /etc/default/xxx.
Also I don't see how is this different from for example dovecot (pop3 and imap server) where master process starts auth, imapd, pop3d,... there just is no master process. This was handled by init script, because it was sufficient for this job. So it seems that systemd is not capable of doing this and "master" script will solve this.
Dovecot upstream actually comes with systemd support including socket activation. I haven't tried it myself but it sounds as if dovecot is perfectly compatible with systemd ;-)
I'm using F15 dovecot package on F14. Works perfectly. (F14 dovecot package omits unit files).