On Fri, Feb 24, 2012 at 10:51:23AM +0100, Svante Signell wrote: > On Fri, 2012-02-24 at 09:16 +0100, Josselin Mouette wrote: > > Le vendredi 24 février 2012 à 08:47 +0100, Bernhard R. Link a écrit : > > > What I try to say is "If there can only be one, then this should not > > > be systemd. So if Debian shall have systemd, it should support multiple > > > init systems." > > > > What we say is: there should be only one, and it will certainly not be > > sysvinit. > > Then you are excluding all non-linux systems. Is that part of Debian > policy? While at the time supporting non-linux systems (like kFreeBSD > and Hurd, and others to come)
It is an interesting question, that we should perhaps re-visit at this time: to what extent should the desire to support non-Linux kernels be allowed to hold back improvements in the GNU/Linux flavor of Debian? We've had this dilemma before, for example, when the X server and the Linux kernel started to become very great friends with KMS. This made it harder to support X on non-Linux kernels. Should we allow kFreeBSD and Hurd (and, possibly, other kernels in the future), which do not support the features required by systemd and upstart, allow us to get away from sysvinit and start using an event based init system? * If we stick to sysvinit, we lose the benefits of event based init. * If we support sysvinit and at least one of upstart and systemd, we make a bunch of extra work for every package that needs init integration. * If we support only systemd or upstart, then we effectively lose non-Linux kernels. The ideal solution would be for Hurd and kFreeBSD to add support for systemd and upstart, but I guess that's not so easy. It would, however, mean that the work would be done by the people who most benefit from it, rather than putting it on the people who probably never even use the other kernels.
signature.asc
Description: Digital signature
