On Tue, May 04, 2010 at 12:04:39PM +0200, Patryk Zawadzki wrote: > > I think Upstart support should be implemented as an option, coexisting > > with current solution, so the administrator may choose what he prefers > > and even use init.d for some services and upstart for other. > > I was hoping for eventually dropping rc scripts for some services and > moving them completely to upstart. I see why that might sound scary > and am ok with having two solutions.
I think we can drop rc-scripts some day, but first the alternative must be well-tested. Having the two alternatives co-exist every one may gradually migrate to upstart in his own pace. And dropping /etc/rc.d/init.d/* in Th will make another difference to Ti… I guess we don't wont PLD split even more. Another thing to consider is LSB compatibility… some services expect /etc/init.d scripts doing their stuff. Maybe we could make /etc/init.d a directory with symlinks to /etc/rc.d/init.d or the upstart wrapper, depending on what is used to handle the service? > I'd opt for having 2 separate -init subpackages, one with the current > rc.d contents and one with an upstart job description and a simple > rc.d wrapper that runs "start $foo", "stop $foo" etc. Extra two subpackages for every daemon? I would prefer to avoid that. > As for emitting signals, we should add these as required by > dependencies. I see no gain from adding them to every rc.d script. Hmm. That makes sense. Some event will be implemented in rc-scripts (line 'network started'). On the other hand, if we make rc-scripts function which does touch /var/lock/subsys/$name; initctl emit subsys/$name started and another to: rm -f /var/lock/subsys/$name; initctl emit subsys/$name stopped Then integrating the signals will be very easy. Greets, Jacek _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en