On 20 January 2014 14:29, Russ Allbery <r...@debian.org> wrote: > Steve Langasek <vor...@debian.org> writes: >> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote: >>> I think (a) and (b) are pretty non-controversial. (c) and (d) are >>> required if we want to deal with new GNOME stuff and anything other >>> than systemd probably, and don't seem very hard to either do or >>> document. (e), (f) and (g) seem like a fairly straightforward of >>> allowing for multiple init systems in Debian. I think something like >>> (i) might be a good way of sunsetting tech ctte decisions so if there's >>> an actual consensus in future, there's no need to get a pro-forma vote >>> from the ctte to make changes in future. YMMV of course. >> For my part I think this is generally a good idea, but I have the >> impression that at least Russ would be strongly opposed to this because >> it's too prescriptive. Probably not much sense in fleshing out such a >> resolution if there's not a consensus for it. > I think this is all great work to do. I'm just dubious about enforcing it > with a technical committee decision. This is the sort of thing that I was > expecting to need to do on the Policy front once we have a decision. I > think that's the right forum for drilling into the details.
Personally, I'm still not really clear on where the ctte is leaning wrt supporting multiple init systems; if the idea is that [OpenRC] becomes the new default, and declares itself as Essential:yes, and the Debian maintainers of [systemd and upstart] say "okay, I give up, I'm going to work on [OpenRC] now", it doesn't seem like there'd be much need for policy work. Obviously, switch the init systems around as appropriate. I believe I've seen comments along those lines from both systemd and upstart maintainers should upstart or systemd be chosen as the default, but maybe I'm mistaken. I'm pretty sure I've seen numerous comments that Debian should only support one init system (per kernel, at any rate), which would make the Essential:yes part make sense. To me that seems like it would be a bad outcome (even if we adopted upstart everywhere and abandoned sysvrc, systemd and openrc entirely; it would still make it unduly difficult to experiment with the next next-generation init systems in a Debian environment). I'd expect the tech ctte's decision to be prescriptive enough that it's clear what non-default-init-system maintainers and users should do, post-apocalypse, I guess. On a practical note, having a quick look at the policy list, it seems like that's not actually crazy active/responsive at present either (long overdue updates to menu policy and triggers documentation are the only topics this month?), so relying on -policy for detail work doesn't seem like it would actually work out in a timely fashion? Honestly, I was a bit surprised that Steve thinks the above's a good idea, given I wrote it from the (my) perspective of wanting to support multiple init systems within Debian; and my understanding is his opinion is that that's kind-of nuts. I think that's pretty great through, especially in that it affirms my naive faith that drilling down into technical details is a good way of achieving consensus amongst people with very different goals and political/philosophical stances... ;) Cheers, aj -- Anthony Towns <a...@erisian.com.au> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
