Hi martin, hi fellow DDs! I really support the idea martin is proposing but I want to see it in a broader scope, not restricted to upstart alone (although I'm very interested in upstart). Currently our support for alternative init systems (like upstart, minit, runit, initng, to name a few) sucks resp. is nonexistent. I'd like to see a better infrastructure which enables to switch to another system without problems (very much like it's today possible to choose your preferred inetd, mta etc.). So I'm going to outline some ideas I've been thinking about how this could be done and I'd be happy to hear comments. martin f krafft wrote: > upstart is looking interesting and it might just as well replace > sysvinit for etch+1. Or at least be an alternative. > > In order to enable this change, we're facing the "To continue type > in the phrase 'Yes, do as I say!'" problem because sysvinit is > marked essential. > > Jeroen said this has been discussed previously, but didn't remember > the outcome. I am strapped for time, so I did not bother reading the > archives as I did not find the discussion during a cursory look, if > someone would shove them in my face, I'd appreciate it. > > My suggestion is to add a package "init-daemon" or maybe "pid1" to > etch, which is essential and depends on sysvinit. Then, make > sysvinit non-essential. I already proposed a similar approach in [1]. My idea was to introduce a new package, let's call it "init" for now, which has priority required and is marked essential. This package would depend on "sysvinit | init-system", where init-system is a virtual package. This init package will also contain some common infrastructure, which I will describe in detail later. When that package exists, the Essential flags would be removed from sysvinit and sysvinit-utils; in addition sysvinit would add a "Conflicts/Replaces/Provides: init-system" (sysvinit beeing the package that ships /sbin/init). The advantage of depending on a virtual package called "init-system" would be, that we wouldn't have to change the "init" package, each time a new init system was added to the archive. It would be up the the new init system package to declare "Conflicts/Replaces/Provides: init-system". We could also switch the default init system easily for etch+n by replacing "sysvinit | init-system" with "foo | init-system" in the init package. New installations would then automatically get the new init system, existing installations could decide to upgrade or keep the old resp. the preferred one. I'd really like to see that happen for etch, because it would make the upgrade for etch+1 (if we decided to switch) easier. > If we have that in etch, migrating to upstart (or just enabling it) > would be as easy as making the dependency "sysvinit | upstart". > > I realise this will be hard to do at this stage, but not impossible. > But thinking ahead, I think we'll save ourselves quite some trouble > later. Agreed. > < jvw> this really is a very very bad time for introducing a new > essential package > < jvw> d-i, debootstrap, etc etc > * madduck pretends to not have heard that last comment by jvw > < jvw> madduck: should I repeat it? > < madduck> jvw: nooooo > > The alternative: > > < jvw> anyway, the only viable solution I see that gets both > no-new-base-packages *and* a non-essential sysvinit so > upstart can be installable without apt croaking in etch+1 is > having another currently essential package depend on sysvinit > | some-init-daemon-virtual-package > > I would consider this a hack, but it might be the best option, and > it should allow us to migrate to my above suggestion for etch+1 > AFAICT. While having a currently essential package having a "Depends: sysvinit | init-system" is surely easier to accomplish and better than doing nothing at all for etch, I think we need a separate "init" package sooner or later to provide a common infrastructure, our packages are expecting, mainly this is update-rc.d and invoke-rc.d which are called in the package maintainer scripts. "init" would provide the two binaries /usr/bin/(update-rc.d|invoke-rc.d), which would be small wrappers calling the actual scripts in /etc/init/invoke-rc.d/ and /etc/init/update-rc.d/ via e.g. run-parts. The sysvinit package (or better sysv-rc), which currently provides update-rc.d/invoke-rc.d, would move its scripts to /etc/init/*.d/. An alternative init system could implement and provide invoke-rc.d/update-rc.d by installing scripts into /etc/init/*.d/. Currently packages like apache, exim, dbus etc. provide sysv-style init script. A new init system would have to provide it's own implementation of this startup jobs (well, maybe not for all of them, but for the most important ones), and make sure, that update-rc.d installs the correct, corresponding alternative. The calls to invoke-rc.d should be translated to corresponding calls, e.g. for initng an "invoke-rc.d start apache2" would translate to "ngc -u apache2". For other systems it could be a noop or something else. This is definitely etch+1 or even etch+2 material, but I think we should set the right course now. As new co-maintainer of upstart I'm willing to work on this but I want to hear your opinions first. If there is agreement on this plan, we could work out a timeline and a more detailed specification. Cheers, Michael [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385722 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature