[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: General Resolution on Init Systems and systemd Facilities

Sam Hartman writes ("Proposal: General Resolution on Init Systems and systemd Facilities"):
> Choice hartmans1: Affirm Init Diversity

I have read through these options and I find them unsatisfactory in
their treatment of what I'm calling `non-init-related declarative
systemd facilities'.  Eg, timer units, sysusers.d, etc.

There are a number of these, and more of them are going to come along.
We need a better framework for handling these cases.  If we do nothing
else then both of your options 1 and 2 lead to a mess.

For example, suppose upstream ship a timer unit.  A Debian contributor
wants to supply a patch to make the package use cron.  You might very
well want to use cron even with systemd; some people prefer cron's
featureset.  How is this supposed to be resolved in practice ?  The
non-systemd-using contributor of the cron job might which to simply
add a dependency on cron and disable the timer unit by default.  Or
are the timer units supposed to be patched to be disabled when cron is
installed ?

It seems to me that these kind of technical details will need to be
resolved via the policy process.  These discussions are specific to
each facility.  In some cases we will want to simply provide an
implementation of (perhaps a subset of) the systemd functionality.

I think these decisions ought to be taken on a faciliy-by-facility
basis.  That's why my proposal sets out a set of criteria for judging
whether a facility's interface ought to be adopted by Debian.  If the
facility is adopted, the non-systemd folks (like me) will have to
implement it; if not, it should not be used and if necessary upstream
arrangements should be patched to use a more general facility instead.

> Choice hartmans3: Focus on systemd for Init System and Other Facilities

If this option wins I will significantly reduce my involvement in
Debian.  I think there are probably other contributors for whom this
is the case.  I imagine that there are contributors for whom option 1
(or Dmitry's option) is similarly awful.

One of the most damaging things the systemd wars have done is to turn
bugs into fights.

Fights are awful.  Bugs are fine.  We have lots of bugs and we enjoy
fixing them.  My proposal is trying to turn the fights back into bugs.


Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply to: