Bug#727708: package to change init systems
Adrian Bunk writes ("Re: Bug#727708: package to change init systems"):
> On Mon, Feb 03, 2014 at 07:45:19AM -0700, Bdale Garbee wrote:
> > I've been trying to avoid making decisions now about what happens beyond
> > jessie, but I would not object to including that text since I think it's
> > true for at least some values of "support".
>
> This discussion started since the
>
> Software outside of an init system's implementation may not require
> a specific init system to be pid 1, although degraded operation is
> tolerable.
>
> in the L rider was interpreted by Russ as being valid forever, while
> I read the whole resolution text (including this part) as only being
> valid for jessie.
>
> Does a TC vote for this strict rule in the L rider make it binding only
> for jessie, or forever?
> This is the important question here.
My view is that the T/L rider should apply to jessie+1 and beyond, as
well as to jessie. The text I have just emailed would IMO do that.
It would be IMO better to make a decision now and explicitly revisit
it if it turns out to be wrong, than to make no decision on T/L for
jessie+1 and definitely have to have the argument again then.
> Note that if a GR would re-affirm the TC decision, then a new GR might
> be needed to change a T/L rider decision if it is not limted to jessie.
A GR can selectively uphold the TCs decision if it wants to.
Ian.
Reply to: