Ian Jackson wrote:
> Enrico Zini writes ("Re: GR: Selecting the default init system for Debian"):
> > I would imagine that among these four options, the middle two would be
> > far less polarising:
> > - we will use systemd, and way to go Lennart!
> > - we will use systemd, although we are concerned about Lennart
> > - we will use upstart, although we are concerned about Canonical
> > - we will use upstart, and way to go Canonical!
All four of those seem wildly outside the TC's purview. This list of
options omits the two least polarising options of all:
- we will use systemd
- we will use upstart
Specifying technical details of how systemd or upstart should integrate
with Debian, where absolutely necessary (as opposed to leaving it to
maintainer judgement) falls within the scope of a TC resolution, and
some of that will be necessary in both of the draft resolutions (to
specify timelines for integration in jessie and jessie+1, transition
plans for sysvinit, etc). However, endorsement or admonishment of
specific package upstreams seems well outside what the TC should be
resolving.
> At the risk of feeding the horrible energy beast I think I need to try
> to propose some wording about these troublesome aspects of systemd.
> Here's a suggested text to accompany versions of the resolution which
> specify systemd as default.
>
> N. We are very concerned about the systemd upstream's history of
> claiming control of wide areas of functionality. We are also
> worried by the vigorous adoption campaign one of whose key
> strategies appears to be making systemd mandatory for various
> other software, even where the benefits of such tight coupling
> are minimal or alternative approaches such as operation with
> reduced functionality would be entirely feasible.
>
> In this context the systemd project's apparent lack of
> prioritisation of the legitimate divergence of wishes and goals
> on the part of its downstreams is especially worrying.
>
> Our selection of systemd as default is made despite these
> worries. We reiterate Debian's commitment to diversity of
> approaches and to the freedom of our downstreams and users to
> make their own choices.
>
> The last sentence can only make sense in the context of a resolution
> supporting multiple init systems for the foreseeable future.
First of all, I'd like to point out the obvious problem with having
chunks of the systemd resolution written by folks who have made it clear
they do not favor that resolution. It seems rather unlikely to me that
a statement like this will suddenly change someone's vote who would
otherwise not have voted for systemd, and it would not surprise me at
all if someone of the folks who *do* intend to vote for systemd would
find the above statement off-putting.
This text in particular is inaccurate, and assumes bad faith on the part
of both the systemd maintainers and systemd upstream, almost to the
point of offensiveness.
Taking it point by point:
> N. We are very concerned about the systemd upstream's history of
> claiming control of wide areas of functionality. We are also
> worried by the vigorous adoption campaign one of whose key
> strategies appears to be making systemd mandatory for various
> other software, even where the benefits of such tight coupling
> are minimal or alternative approaches such as operation with
> reduced functionality would be entirely feasible.
- systemd upstream has not "claimed control of wide areas of
functionality"; it has incorporated functionality where it can provide
better integration with the rest of the system. And that
functionality is generally provided in discrete chunks, most of which
are not mandatory. If you're seeing them more widely used, perhaps
that's because they're *useful*.
- The phrasing is such that it's not clear whether this is complaining
about systemd's general goal of being more widely adopted or about the
specific issue of increasing dependencies on systemd. I'll assume the
more charitable wording, since there's absolutely nothing wrong with a
piece of software trying vigorously to be adopted, and this statement
should not imply otherwise. For the latter point, see the next item.
- Making systemd mandatory for other software is not merely a tactic
"vigorous adoption campaign"; whether you're willing to acknowledge it
or not, it's being done in cases where there are legitimate technical
benefits to depending on systemd and its components. This is one of
the points where your proposal assumes bad faith.
- If "alternative approaches such as operation with reduced
functionality would be entirely feasible.", feel free to write and
maintain those alternatives; don't expect systemd to maintain
alternatives to *itself* because you don't want to use systemd. Why
would the systemd developers or maintainers want to do extra work to
encourage non-use of systemd? I certainly wouldn't expect the upstart
developers to go out of their way to support systems not running
upstart, beyond that needed to allow smooth transitions from another
init system to upstart.
> In this context the systemd project's apparent lack of
> prioritisation of the legitimate divergence of wishes and goals
> on the part of its downstreams is especially worrying.
Speaking as someone who has followed the development of systemd since it
was created, the systemd maintainers have taken quite a bit of care to
work with downstreams who have varying needs. The components of systemd
have accomodated areas of distribution divergence and aided in smooth
transitions, even in areas of gratuitous divergence (e.g. distributions
using different configuration files for the same thing). systemd has
tried to adopt the best technical solutions from a variety of
distributions; for instance, using /etc/hostname from Debian and
changing Fedora and other distributions to match. (Lest you think
systemd will make Debian always conform to Fedora rather than the other
way around...)
In short, systemd has put a great deal of prioritization on the needs of
its downstreams. And if Debian becomes one of those downstreams, I
fully expect to see Debian's needs taken into account. In particular,
if Debian has a solution that works *better* than one in systemd (rather
than just working *differently*), I'd fully expect to see systemd
adapting to work with that solution, and potentially helping Debian
spread that solution to other distributions as well.
That said, systemd is *also* working to harmonize areas of gratuitous
divergence in distributions, where there's no reason other than
hysterical rasins to continue being different. And that's a feature,
not a bug. In those areas, Debian ought to take part in the discussions
about which approach to adopt, and then support a careful transition to
that approach. It's reasonable to expect Debian, systemd, and other
distributions to cooperate with each other; it's not reasonable to
expect systemd to do all the adapting, which is what the text you posted
seems to assume.
Now, with that spirit of future cooperation in mind, I would suggest
something more like the following, if and only if this is deemed
important enough to form part of the systemd resolution and the systemd
proponents are in favor of it as well. Also note the use of
[non-binding advice brackets].
[
- The Technical Committee encourages Debian maintainers of systemd and
other packages to work with their upstreams, downstreams, and
counterparts in other distributions, to achieve the best possible
integration between systemd and Debian. In particular, we would
recommend avoiding gratuitous divergences from existing Debian
behavior and expectations, as well as avoiding gratuitous divergences
from upstream systemd behavior. In cases where the those two differ,
we encourage collaboration to determine the best possible solution for
both upstream and Debian, to provide for smooth transitions for any
resulting changes, and to accommodate users of other init systems
where reasonably possible.
]
Personally, I believe this falls in the area of "package maintainers
should already know this and do this anyway". However, if there's a
consensus that the TC resolution needs to say something about this, and
in particular if none of the TC members favoring systemd would object to
voting for a resolution that included it, then I'd suggest something
closer to the above as a clear statement of *cooperation*, rather than a
demand that systemd conform to Debian (discounting the possibility that
Debian could ever change to adopt what might be better alternatives).
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140120174045.GA5829@jtriplet-mobl1
