On Fri, Feb 07, 2014 at 02:41:39PM +0000, Ian Jackson wrote:
> Colin Watson writes ("Bug#727708: Call for votes on init system resolution"):
> > Agreed on both counts. I understand why Ian (was it?) wanted to have
> > the "multiple init systems for the foreseeable future" text, as a
> > statement of general intent, and I don't disagree with that. But I
> > would prefer if the specifics ("Therefore, for jessie and later
> > releases:") were marked simply as "Therefore, for jessie:". That seems
> > to dispose of part of your objection to L.
>
> I'm afraid that I would be categorically opposed to that change. That
> would relegate L to a mere transitional provision.
>
> I think making the commitment to diversity a long-term intention is
> critically important.
OK. So I agree that long-term commitment to diversity is important. I
just don't necessarily agree that the way in which we do so will stay
the same. For jessie, this amounts to keeping sysvinit support around,
having sufficient non-systemd support available for recent logind and
other new features required by major desktop environments, and not
having a dependency structure such that people end up having to install
a specific init system just in order to keep their systems working.
For later releases, it's not clear to me that we will have the same
constraints. We might reasonably expect sysvinit support to be less
important, and there are various ways in which diversity criteria could
be met. It is for example possible that some new feature of systemd
might have a compatible implementation directly in upstart's pid 1
rather than externally. It's not clear where that sort of thing would
sit relative to L: it wouldn't require *a* specific init system, but it
might exclude some; on the other hand, the presence of two compatible
implementations of an interface should make us substantially more
confident that more are possible, and so I don't think this
automatically implies a lack of diversity.
I think L needs to exclude that sort of thing for jessie as a practical
matter of upgrade handling, but not necessarily for later releases. But
I don't feel comfortable with us drafting the details of the later parts
of that now, when there are so many unknowns, and reasonable
possibilities of compatible implementations being developed for the
specific details that are currently sticking points.
--
Colin Watson [cjwat...@debian.org]
--
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/20140207151145.ge2...@riva.ucam.org
