Bug#727708: init system coupling etc.
On Thu, Feb 20, 2014 at 02:31:06PM +0000, Colin Watson wrote:
> On Wed, Feb 19, 2014 at 06:55:31PM -0800, Russ Allbery wrote:
> > If you do mean that all packages with init system configuration have to
> > ship sysvinit scripts, I wish the wording would actually say that. This
> > potentially matters in the long run. For example, consider a hypothetical
> > future world in which systemd, upstart, and OpenRC are packaged for Debian
> > and sysvinit has gone away. In that world, I would maintain separate
> > configuration for systemd, upstart, and OpenRC, since I consider
> > maintaining those three separate files to be easier than maintaining a
> > sysvinit script. Is that permitted? If it is permitted, does my package
> > become instantly buggy when someone packages openlaunchd for Debian?
>
> I've gone back and forth in my own mind about how/whether we ought to be
> sunsetting this stuff, so apologies if this contradicts something I've
> previously said. My preference is (to borrow a phrase from British
> constitutional law) that the TC should not be trying to bind its
> successor. I'm entirely happy for us to set policy (or give advice,
> whatever) based on how things stand at the moment, and revisit it later
> when the landscape changes.
>
> I know we're all tired of this debate at the moment. But if and when
> sysvinit goes away, I think it'll be relatively straightforward by
> comparison to establish revised policy in light of that, and it will be
> much clearer then what that policy ought to say than it is now. There
> doesn't seem any danger that we'll forget about this.
Also, after rereading your proposal, I notice you have a post-jessie
sunset clause where we would have to renew our advice if we wanted it to
continue to be effective (is this very meaningful in an informative
context?). While I agree with your too-many-variables sentence, I
prefer this indefinite until-we-decide-otherwise approach, because
engineering timescales are wildly variable even in the corporate world
never mind in a volunteer project. We definitely want our
advice/policy/whatever to be effective up to the release of jessie for
practical upgrade reasons, but I would prefer that changes after that be
in response to definite changes in the init system landscape, rather
than simply the passage of time and Debian releases.
--
Colin Watson [cjwatson@debian.org]
Reply to: