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 [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org