Bug#727708: On diversity
On 17 January 2014 03:52, Ian Jackson <ijackson@chiark.greenend.org.uk> wrote:
> What is Debian ? In one respect, Debian is an operating system. And
> of course in another respect Debian is a community.
> * Debian is a forum for cooperation and technical development.
> * Debian, as a piece of software, tries to be all things to all
> people (within reason).
So the original message referring this to the tech ctte was about
deciding on "the default init system". Honestly, that seems like the
least interesting part of this discussion to me; and I wonder if the
ctte shouldn't consider answering some different, but related question
that more directly addresses issues like packages depending on cgroups
or logind. Something like:
a) maintainers should be aware cgroups is a Linux-only feature; if
their package requires the use of cgroups to be usable it should be
configured to not build for non-Linux architectures.
b) maintainers should be aware systemd relies heavily on cgroups, and
thus should be aware that requiring use of a systemd unit file for
startup will likewise require their package to be configured to not
build for non-Linux architectures.
c) logind or an equivalent service implementing the freedesktop.org
systemd/logind api should be available under all supported init
systems and architectures in Debian. It should be provided via a
virtual package "fdo-logind" and packages (such as desktop managers)
expecting logind to be available should Depend on fdo-logind
d) [are packages likely to start depending on
localed/hostnamed/timedated/machined/??? in the same way as logind
such that it would need to be available outside systemd for upstart to
be a useful init?]
e) no init system in Debian should be marked as Essential:yes, or
depended upon by any Essential:yes or Priority:required package except
through the virtual package "init-system". All init packages should
Provide: and Conflict: init-system. base-files should Depend:
init-system.
f) all init systems Providing the init-system virtual package must
support packages providing sysv style init scripts via update-rc.d.
g) packages that do not work with sysv must declare a Depends: on the
init systems they do support, eg upstart | systemd
h) having examined the various current available init systems, the
tech ctte considers [OpenRC] to be the best available init
implementation at present, and so determines that the relevant
maintainers, including the installer team and ftpmasters se it as the
default init-system for new Debian installs. This decision becomes
vacant should a general resolution specifying an alternative init
system as the default pass with a simple majority prior to jessie's
release.
i) all these decisions revert to advisory opinions after the release
of jessie, and may then be changed by the usual methods of consensus
driven policy development, and maintainer decisions, or by referring
the issue to the tech ctte again.
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.
In my ideal world, the tech ctte would work out good answers to all
the bits above except (h) and get those added to policy, then propose
various options for (h) as a GR themselves, with well argued
rationales for each of the options along the lines of what's already
been posted to the list. How much that conflicts with the "No detailed
design work" portion of the ctte's mission statement is up for debate
though. Why you'd have a *technical* committee and forbid them making
sure the "details" are right doesn't make a lot of sense to me though.
Fortunately I'm not on the tech ctte list, so I can look into details
all I like ;)
Cheers,
aj
Reply to: