Re: Fast start-stop-daemon in C
Marek Michalkiewicz writes ("Fast start-stop-daemon in C"):
> Some time ago I wrote a faster C replacement for the start-stop-daemon
> perl script. I use it for some time now (the most recent changes were
> just a nicer help screen; the code is quite stable).
>
> This makes the system boot faster (especially on low end machines),
I'd be very happy to include this in the dpkg source tree, but after
the 1.1 release. Can you remind me then ?
> and important system startup scripts no longer depend on another big
> package (perl). Maybe in the future we can get to the point where
> a minimal system will work without perl installed at all (packages
> which need it in {pre,post}{inst,rm} scripts would depend on perl).
Hmm, this would be quite a big policy change (and would require a lot
of Pre-Depends). Remember that install-info and many other programs
are written in Perl.
> The only problem known so far to me is that I have to reinstall this
> program after every dpkg upgrade which overwrites it with that nice
> slooow perl script :-).
Try using dpkg-divert.
> Just compile this program and drop the binary in /usr/sbin instead
> of the original /usr/sbin/start-stop-daemon perl script (make a copy
> of it first, just in case). See below for source code. I placed it
> in the public domain, but if it has to be GPL-ed to be included in
> dpkg, just tell me. Including it in dpkg would close Bug#1670.
When I include it in dpkg I shall probably GPL it, if that's OK with
you.
> I am posting it here so that it can be tested by more people than
> just me. Bugs are unlikely though.
One thing you could do that would make it much nicer for me to include
in the dpkg source tree would be to have it use
dpkg/dselect/dpkg-deb/dpkg-split/&c's standard common argument
parsing, error handling, malloc wrapper, &c scheme. You'll find that
looking in the dpkg source tree's lib and include directories, and
using dpkg-split (say) as an example, ought to be quite enough
information anyway.
If I include your code it'll be on those terms anyway, and it'll be
much faster if I don't have to do the work myself :-).
Thanks,
Ian.
Reply to: