[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Daemontools wrapper packages



Hi,

We have discussed some weeks ago how to write daemontools wrapper packages to 
have an easy possibility to setup init.d-style services like proftpd under 
daemontools. I'm currently trying to create such a package, but have two 
problems. First let me explain, how I am doing it:

The package is installing two conffiles: /etc/proftpd-sv/run and 
/etc/init.d/proftpd. I dpkg-divert the original /etc/init.d/proftpd in 
preinst (install-target) and re-divert it in postrm (purge-target). This is 
already working fine. The init.d-script provided by my wrapper package is a 
compatibility frontend for svc. Now the two problems:

1. Every time I install my wrapper package I am asked:

  Configuration file `/etc/init.d/proftpd'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
     What would you like to do about it ?  Your options are:

What can I do to prevent this question? I am not touching the original 
/etc/init.d/proftpd, it's already diverted by the preinst script. Or is it 
just not a good way to divert a conffile? If I can't do that, we have to 
rediscuss the issue.

2. lintian says:

  E: proftpd-sv: unregistered-script-in-etc-init.d /etc/init.d/proftpd 

I can't register the init.d script, because it's already registered (because 
it's only a replacement). I can hide this error by calling update.rc.d in 
simulation-mode, but that makes no sense ;-)

Looks like this method is still not clean enough. I wonder if this is the way 
we should do it. Another solution is diverting the proftpd-binary to prevent 
the init.d-script to do anything, but this method can't provide a 
compatibility-init.d-script that some people here wants to see in the package.

Looks like I need some advise, before I am packaging a packge nobody is happy 
with.

-- 
Bye
K



Reply to: