Anthony Towns writes ("Bug#727708: init system other points, and conclusion"):
> I wonder if folks could clarify what status they expect secondary init
> systems to have in Debian?Thanks for bringing up this point so very clearly. I agree entirely with the thrust of your argument. I would very much like to support multiple init systems. Because you can only have one init system at once (unlike databases, but like MTAs and webservers), I think it's reasonable that our goal should be that pretty much every program should at least basically work with every init system, and that most programs will work well with all of them. For non-forking startup protocols, I think we should (for jessie+1 perhaps) define a supported set of protocols. Every daemon package should implement one of the supported set, and every init system (including sysvinit if anyone cares to continue to maintain it) should implement all of them (whether via some kind of compatibility shim or otherwise). For the per-init-system job/unit/whatever files, if we can't come up with some kind of meta format or compatibility converter(s), I would actually prefer to require every daemon maintainer to supply two or perhaps three such task specification files. For admin tools and the like (eg systemd-ui or the gnome control panel) I think it's OK for some of the functionality not to be fully available with every init system. This is particularly true if the functionality is for manipulating features that aren't available in the unsupported systems. If it's just a case that the admin tool doesn't know how to talk to the relevant feature, or the admin tool's model makes assumptions about the underlying init system, then Debian should welcome contributions of the missing pieces, in whatever is the appropriate form for those pieces. That might be (for example) simply glue code, or it might be replacement UI elements which appear when the other init system is in use. Those pieces might be in the same or separate packages, however is most technically and socially convenient. > Forced to make a choice, should Debian go for smoother/tighter > integration between apps, or more choice for users/sysadmins? I'd > expect Debian to choose the latter; though Ubuntu, Red Hat and > possibly Fedora might choose the former. For the wellbeing of the whole free software community, and particularly for our downstreams, we should be aiming for flexibility. Ia. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
