Bug#727708: On diversity
On 20 January 2014 14:29, Russ Allbery <rra@debian.org> wrote:
> Steve Langasek <vorlon@debian.org> writes:
>> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
>> For my part I think this is generally a good idea, but I have the
>> impression that at least Russ would be strongly opposed to this because
>> it's too prescriptive. Probably not much sense in fleshing out such a
>> resolution if there's not a consensus for it.
> I think this is all great work to do. I'm just dubious about enforcing it
> with a technical committee decision. This is the sort of thing that I was
> expecting to need to do on the Policy front once we have a decision. I
> think that's the right forum for drilling into the details.
So I wondered what it might look like to say the same thing in a
minimally prescriptive way. Not even going to try guessing if this is
anywhere sufficient as far as Russ is concerned -- I'm not claiming to
know where Russ might draw the line on that topic. I've also added
some minimal tech ctte-esque boiler plate; I'm sure Ian could do
better.
---
The tech ctte determines as follows:
[non-essential-init] In order to allow Debian users and developers
to easily design, test and deploy alternative init systems both now
and in the future, no init system in Debian should be provided via an
Essential:yes package.
[default-init] Having examined the features and bugs of the various
init systems packaged for Debian, the default init system for jessie
for Linux architectures shall be {OpenRC | systemd | upstart |
determined by a GR}.
The tech ctte further offers the following advice to maintainers:
[logind] The systemd/logind API provided by systemd and documented
on the freedesktop API will be important for a number of packages, and
that API should be made available within Debian for users of init
systems other than systemd. The various non-systemd init system
maintainers are encouraged to work with the systemd maintainers and
upstream to limit the code duplication that may result from this, and
to ensure enhancements and bug fixes are as widely available as
practical (both within Debian for different inits/architectures and
upstream). The maintainers involved should work through the policy
process to establish a virtual package for this API if needed.
[required-init] In order to avoid users mistakenly removing all init
systems from their machine, we recommend the init maintainers
establish a virtual package (eg, "init-system") that all init systems
in Debian both provide and conflict with, and that an Essential:yes
package depend on that virtual package. This should be undertaken
using the normal policy process.
[init-minimal-compatability] In order to make it simple for packages
to work with different available init systems, a simple means of
providing a startup script/configuration that is understood by all
Debian init systems should be documented in policy as a requirement
for for packages providing the init system virtual package. This may
be providing a sysvinit style script and adding it via update-rc.d for
instance. This method may be assumed to always be available if the
[required-init] advice is followed, and thus packages can avoid a
dependency on the virtual package.
[init-crossgrades] In order to provide a good user experience when
switching init systems, maintainers of init systems other than the
default should test converting both to and from their init system, and
that the system is able to correctly shutdown and restart after
transitions to different init systems.
[init-related-patches] Maintainers should accept non-intrusive
patches to provide enhanced support for init systems (both for the
default init and other inits included in Debian). Patches may be
considered intrusive by the maintainer if they introduce additional
dependencies or significant patches to code that are not accepted
upstream. Patches that merely add files to the package or provide
extra code to maintainer scripts should generally not be considered
intrusive. Where a reasonable amount of time has been given to the
maintainer to review proposed patches via the BTS, and no objection
has been raised, a NMU to incorporate the patch is appropriate.
[cgroups] 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. Where
cgroups support is a compile-time feature, it should generally be
supported on Linux architectures, and disabled on non-Linux
architectures, for the same reason.
[systemd-portability] Maintainers should be aware systemd relies
heavily on cgroups and potentially other Linux-only features, and thus
should be aware that unless/until this changes, requiring use of a
systemd unit file for startup will likewise require their package to
be configured to not build for non-Linux architectures.
---
I think the [non-essential-init] and any of the four options for
[default-init] would 100% satisfy me personally, and I think they're
pretty minimally controversial ideas? YMMV. 100% is an approximation.
I think given all the discussion, providing some specific /advice/ on
how to go forward beyond "hey, X wins!" is a good idea and not too
prescriptive. YMMV, again, obviously. The above are the things I think
are important and valid issues to address based on the discussion I've
seen; and I don't think the advice above would actually be terribly
controversial. YMMV on that too, of course.
Comparing with Ian's draft in in the tech-ctte git:
- non-Linux ports is left up in the air
- requiring sysvinit scripts and whether that's an RC bug or not is
left as someone-else's-problem as part of [init-minimal-compatability]
- depending on a specific init is left to maintainer's discretion;
modulo patches/NMUs
- providing native support is left up in the air; modulo patches/NMUs
- my "reasonable" test for patches is more restrictive -- if upstream
don't accept code changes, the maintainer can consider it unreasonable
- [7-11] in Ian's proposal seem "prescriptive" to me, so aren't
addressed in the above for that reason
Again, YMMV, FWIW etc. It seemed an interesting intellectual exercise
to make it less prescriptive, and I think the result's somewhat
interesting. Feel free to build on it, tear it apart or ignore it as
appropriate. :)
Cheers,
aj
--
Anthony Towns <aj@erisian.com.au>
Reply to: