Hi together, first of all, sorry for being so late to this party.
I'll start with describing a few facts, observations and thoughts, and come to my conclusions at the end of this mail. I don't write references at places where I believe had already sufficient coverage by others and/or are more or less not really doubted. I also didn't write at all possible required locations "as far as reasonable" or similar - I assume and expect that we all try to integrate our system as good as reasonably possible without wasting too much time for details nobody cares about, and I didn't want to write it at all places again and again. (And just because something is technically possible doesn't mean it is reasonable possible, and if I write "possible" below it refers to "reasonable possible", and same with similar words.) Also I try to not repeat too much of what had already been written by others, especially in other summaries. What are we speaking about? There are three different things: The pid1-provider, means: what is init in the terms of the linux command line (current default: sysvinit). Then the runlevel-manager (current default: sysv-rc). And then a daemon which could start and stop other services (which is always provided by the pid1-provider, but there are other in Debian, and as long as they could be used at the same time together, I don't think there is any conflict, and so no reason for a decision). Also, as discussion has shown, we speak about what is default in Debian (please note that this could be more than one overall, so it might be "defaults in Debian"). Then, what is required to be supported (at least what is default anywhere on a architecture in testing). And then what else are maintainers supposed to support on an higher than wishlist level. State of the different init systems: First of all, I think that all three contenders are better than our current state. Systemd and upstart are way better, openrc still is a major improvement about sysv-rc. So all three are in the game for me. I however don't believe that we could realistically support all three (four) equally good at the same time. It might had worked if somebody would have found a clever meta-format that could be autoconverted by debhelper in almost all cases, but as none is there yet I doubt it's realistic. It might work that we support two of them at the same time, but even that is a bit painful for us (and there should probably be some autotesting then as suggested by Anthony recently). So, what could realistically work: On the linux ports, all would work. On the kbsd ports I believe that both upstart and openrc could be working, but none is yet. For hurd, at least openrc could and probably also upstart. Porting systemd to kbsd or hurd is not realistic from what I understood (unless they basically clone the linux cgroups feature), but a parallel implementation of programm with similar configuration files would be possible (but I don't believe in that, especially for the long-term maintenance[1]). Porting upstart seems to be possible, but has the CLA-issue which makes flowing patches back to upstream harder (and therefor I would recommend Canonical to not use this policy for upstart), so we would have to carry extra patches within Debian (which however doesn't look as painful as a parallel implementation of systemd). Openrc looks like it could work "in the upstream way" everywhere, but needs a bit of porting. I don't believe that it would work long-term if we use systemd on Linux and upstart on !Linux. [1] Having a parallel implementation of systemd for kbsd would mean that we also need to take care that e.g. logind is useable without systemd. Which however means that we'll have the same work required to use non-systemd as default on Linux plus some additional work for the systemd-mimikri. Doesn't sound too attractive to me. All of that together boils down to these options for the default pid1-provider / runlevel manager (perhaps after some more porting in this cycle): 1. Systemd on Linux, openrc/sysv-rc on non-Linux 2. Upstart everywhere (3. openrc/sysv-rc everywhere - as both systemd and upstart are better, I don't think this ends high enough on my priority list; see below for details) What does "required to be supported" mean? Basically the same as always - the basic functionality needs to be good useable, and everything else reasonable supportable as well. And any "required to be supported" provider needs to be supported at least to the same amount as any other. This doesn't mean that functionality needs to re-invented just because it is technically possible. To take an example from a recent irc conversation, I don't think it's sensible to expect people to do multi-instance setup in sysv-rc just because it is technically possible (but extremly painful) and it is done in (systemd or upstart), but on the other hand, if systemd would be the default and sysv-rc not anymore and someone does multi-instance in sysv-rc I would expect it to be done in systemd as well. Also the question did arise what programs are allowed to depend upon? Could some program say it needs one specific pid1-provider or runlevel-manager? For the question of "could Y be required as a supervising daemon" (like cereal depends on runit) I think we all agree it is possible, as long as Y doesn't require to be alone on the system (i.e. it doesn't require to be able to exclusivly control ressources); this even isn't for me for the tech ctte to decide because I don't think someone asked us that question. For the runlevel-manager and pid1-provider, I don't think that programs should be allowed to require one exclusivly - of course, some advanced functionality might be restricted to some managers/providers, but the program should not be unnecessary limited and willing to integrate other runlevel-manager/pid1-provider to the same amount if they provide same functionality. Support of more than one pid1/runlevel-manager? This is one of the core questions. If we end up with an init system which only works on Linux, we need to support at least two (however perhaps on Linux only one and another one only on non-Linux). Expecting that we could support all three realistically well is an expectation I am not sharing. However, I think we could have the expectation that our users should be able to exchanges those providers without the system totally falling to pieces or deinstalling core components of the system (like people could today - e.g. runinit could be used to name one not on the hotlist of many minds). I also think we should have the expectation that exchanging of initsystems should continue to be a possiblity (this is more a mindset-question - because of course as today it might mean that people would have to invest time into that, but I could consider many reasons for a debian derivative to use e.g. openRC as provider; as said I don't expect to be easily possible but we should still be welcoming people trying other init systems, and be happy about accepting patches when they're ready). So we could converge on one pid1/runlevel-manager only if we choose one which is (going to be) available on all platforms. Support of !linux platforms >From a long-term perspektive our non-linux-platforms as well as the non-x86-linux platforms have done us very good in getting our code in good shape, and help even on the mainstream linux platforms to find bugs earlier / better (e.g. hurd with removal of static buffers). For details see e.g. http://lists.debian.org/[email protected] For this reason, I consider it important to make sure our non-linux-platforms are reasonable well supported. Vendor lockin This is a question which is relevant for both Upstart and Systemd. Answers are different, but I'm not happy with either Upstart being so canonical-centric (yet?) and systemd pulling more and more parts of the base system into it. The later gives me even more concerns, because it means that our current flexibility in some of these parts will be steadily going down in the long run (see e.g. the relation between kbd and systemd in Collins mail for what that means - we are trading parts of our quality for more systemd integration, and I'm not sure that this is always a good trade). In fact, systemd would look better to me if it would be less invasive. Implementation details For openrc, this is a moving target. When I looked at it first during the start of this discussion, it was not even in experimental (and still is not in unstable), and documentation was hard to get. This has improved but still it is worse then the others. Also having a no-double-fork-setup for demons is something really useable, and I haven't seen any answer on that during time of writing this. I appreciate the work that had been put into openRC, and I believe openRC is a major improvement over sysv-rc, and will also continue to have a useful place in the linux/unix ecosystem. I recommend openRC developers to keep up their good work. However for Debian I think it will not be our default choice for the Linux-architectures. Sorry. For systemd / upstart I also refer here mostly to other mails, e.g. http://lists.debian.org/[email protected] Systemd and upstart both have made different decisions implementation wise, but in the end the core topics (e.g. service startup notification, dependencies vs events, format of configuration files, documentation) are reasonable well resolved, so that I don't think that makes a relevant difference for the decision. (For the service startup notification I would recommend both to support the other protocoll as well, but nothing which should be part of a resolution.) Logind support for !systemd-based systems Logind seems to become an vital part for any desktop service. I seriously hope it will be continued to be maintained in a way that doesn't require systemd (independend of how debian decides for the pid1-provider), even though since release 205 this is harder or needs to be forked. See e.g. http://lists.debian.org/[email protected] for details. I don't see how this would be part of a decision right now, but is an important detail. (Some more details about cgroups, linux-centrisms, problems of that etc are in http://lists.debian.org/cajs_lcxtps1xdy6owf6eqwz5jwujccj0sio8kadakqwv2k8...@mail.gmail.com - and thanks Anthony for your good mails in the current discussion). Now, putting that all together, from the options above "systemd for Linux, openrc/sysv-rc for !linux" or "upstart everywhere" I prefer the upstart choice. Reasons for this see many details above, supporting all the required features, not as invasive in the debian system, saving us to integrate more than one init system reasonably well etc. Andi -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
