Sam Hartman writes: > Choice hartmans3: Focus on systemd for Init System and Other Facilities > > Using its power under Constitution section 4.1 (5), the project issues > the following statement describing our current position on Init > systems, Init system diversity, and the use of systemd facilities. This > statement describes the position of the project at the time it is > adopted. That position may evolve as time passes without the need to > resort to future general resolutions. The GR process remains > available if the project needs a decision and cannot come to a > consensus. > > The Debian project recognizes that systemd service units are the > preferred configuration for describing how to start a daemon/service. > Packages should include service units or init scripts to start daemons > and services. Unless the project or relevant parties have agreed > otherwise, systemd facilities, where they exist and are stable and > supported by the systemd maintainers, should be preferred over > Debian-specific ways of solving the same problem unless the Debian > approach has clear and obvious advantages. > > > Providing support for multiple init systems or for alternatives to > other interfaces provided by systemd is not a project priority at this > time. > > Debian is committed to working with derivatives that make different > choices about init systems. As with all our interactions with > downstreams, the relevant maintainers will work with the downstreams to > figure out which changes it makes sense to fold into Debian and which > changes remain purely in the derivative. > > Packages may include support for alternate init systems besides > systemd. Maintainers use their normal procedures for deciding which > patches to include. Seconded. I think we should eventually move on from sysvinit-compatible init scripts as mandatory lowest common denominator for all init systems and so far this is the only proposal which seems to allow so. Ansgar
Attachment:
signature.asc
Description: PGP signature