On 10.04.2012 01:07, Steve Langasek wrote: >>>> I'm wondering if this couldn't be handled in invoke-rc.d though. >>>> If upstart is running, and there is a native upstart job, which is not >>>> running though, invoke-rc.d could just call /etc/init.d/foo stop > >>>> In postinst, when you run invoke-rc.d foo start, it would then start the >>>> upstart job. >>>> Wouldn't this cover this upgrade case? > >>> It would; I just don't think invoke-rc.d is the right place for that >>> complexity to live. For instance: if upstart is running, there's an upstart >>> job for foo, job foo is not running, and invoke-rc.d calls >>> /etc/init.d/foo stop as a fallback: how should invoke-rc.d handle the exit >>> code of /etc/init.d/foo? > >>> All possible answers to that question are sufficiently irksome that I >>> think we should avoid putting the complexity in invoke-rc.d. > >> invoke-rc.d already needs to be upstart aware, so this seems like the >> right place to put this logic imho. Putting it in each and every sysv >> init script on the other hand looks wrong to me. > > You didn't actually answer the question I posed here. How should > invoke-rc.d handle the exit code of /etc/init.d/foo to make this not suck in > the corner cases? What specific problems do you have in mind here. It's not really possible to answer the question for some hypothetical issue. > If you don't have an answer for how to make this reliable, I don't think > this aesthetic preference counts for much. I don't think code duplication and offloading the problem to each and every maintainer is a astetic preference. It's pretty obvious to me that pulling upstart specific details into sysv init scripts is a bad idea, especially for package maintainers who don't use upstart. I would much rather prefer a well tested implementation in invoke-rc.d that is written and maintained by people who know about upstart. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Description: OpenPGP digital signature