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

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: