[12:25] Shred01: No, that won't work. [12:26] is there any reason not to emit events for those old initscripts? to help interfacing newer ones with older ones? [12:28] Do you know, how the current sysv compat layer works? [12:28] upstart basically has two jobs: rcS and rc-default (which by default runs rc2). [12:29] These two jobs simply run /etc/init.d/rcS and /etc/init.d/rc 2 [12:29] If you wanted feedback from the old sysv initscripts, you'd either have to modify /etc/init.d/rc or the initscripts directly. [12:30] And place corresponding "initctl emit $foo" call in their. [12:31] s/their/there/ [12:33] mbiebl: exactly. i'd of course opt for modifying /etc/init.d/rc. [12:34] I guess, the reason why it's not done, is simply that it is not really needed. [12:35] Do you have any good use cases? [12:37] And modifying /etc/init.d/rc won't address the problem, that you can start/stop services via /etc/init.d/$foo. [12:39] So you'd have to modify all initscripts and add "initctl emit $foo $changed_status" everywhere. [12:39] A lot of work that would be not worth the effort imho. [12:40] mbiebl: that is true. i guess i am just looking from the "orderly starting of services" POV. the use case is mythtv's existing mythtv-backend initscript. i want to write an upstart script for myth's frontend (which is not included in the frontend package as an upstart or initscript) but it really can't start until the backend has started. [12:41] You would write an upstart job for the backend first. [12:41] Replace the initscripts from the bottom up. [12:42] sure, but then i have a one-of that i need to remember to keep replacing every time i get a mythbackend update. [12:43] i'm just being impatient i guess and not seeing the point to writing an initscript for mythfrontend vs. writing an upstart script for it. [12:43] You could write an upstart job which runs at "start on stopped rc2" [12:44] This means, it is started after runlevel has been started completely, which means, the mythtv backend should be running. [12:44] ahhh. after all of the initscripts are run. [12:44] right. [12:45] correct. [12:49] is upstart-for-everything supposed to happen in gutsy or post-gutsy? [01:11] Shred01: I guess that not all services will be converted for gutsy but only the main ones. [01:11] cool enough i guess === Md [i=md@freenode/staff/md] has joined #upstart === mbiebl [n=michael@e180067242.adsl.alicedsl.de] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === phoenix24 [i=vkiek@ns37986.ovh.net] has joined #upstart === juergbi [n=juerg@80-219-19-183.dclient.hispeed.ch] has joined #upstart === thom_ [n=thom@amnesiac.heapspace.net] has joined #upstart === phoenix24 [i=ceziwra@ns37986.ovh.net] has joined #upstart === Amaranth [n=travis@ubuntu/member/Amaranth] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === sadleder [n=sadleder@p50814386.dip0.t-ipconnect.de] has joined #upstart === Trevelyan` [n=OO6@unaffiliated/trevelyan] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === phoenix24 [i=fadsi@ns37986.ovh.net] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Md [i=md@freenode/staff/md] has joined #upstart === Keybuk [n=scott@quest.netsplit.com] has joined #upstart === wasabi_ [n=wasabi@cpe-76-184-122-13.tx.res.rr.com] has joined #upstart === sadleder [n=sadleder@p50814386.dip0.t-ipconnect.de] has left #upstart [] === juergbi [n=juerg@80-219-19-183.dclient.hispeed.ch] has joined #upstart === Trevelyan` [n=OO6@unaffiliated/trevelyan] has joined #upstart === mbiebl [n=michael@e180072132.adsl.alicedsl.de] has joined #upstart === tck [n=tck@213-202-153-56.bas503.dsl.esat.net] has joined #upstart === mbiebl [n=michael@e180072132.adsl.alicedsl.de] has joined #upstart === tck [n=tck@212.2.165.61] has joined #upstart === mbiebl [n=michael@e180072132.adsl.alicedsl.de] has joined #upstart