Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Tollef Fog Heen]

]] Cameron Norman 

Please trim bits you're not replying to.

> El mar, 21 de oct 2014 a las 10:19 , Tollef Fog Heen 
> escribió:
> > ]] Russ Allbery

> >> I would be particularly interested in your take on the analysis
> >> that Steve Langasek posted to the debian-devel thread on why
> >> listing systemd-shim as the first alternative dependency for
> >> libpam-systemd makes sense and should not cause any negative
> >> effects for systemd users.
> >
> > In a steady state, this would probably be ok. However, we've so far
> > seen two instances of -shim breaking for systemd users
> > (https://bugs.debian.org/746242 and https://bugs.debian.org/765101),
> > by shipping outdated security policies. We are worried that this
> > will happen again on future updates of systemd.
> 
> Josh Triplett proposed a long term solution to the problem you point
> out here that will work across systemd upgrades. What are your
> thoughts on that solution?
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101#38

That seems like a fine approach to me.  I thought it already depended on
systemd, though.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2h9ywhakn@rahvafeir.err.no

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Cameron Norman]

El mar, 21 de oct 2014 a las 10:19 , Tollef Fog Heen  
escribió:

]] Russ Allbery

Hello Russ, CTTE,


 Hello, systemd maintainers.

 We (the Technical Committee) have received a request to override a
 maintainer decision around whether systems are switched from 
sysvinit to
 systemd on upgrade.  However, it's not clear to me that an actual 
decision

 has been made that we would need to override.

 There have been multiple (fairly high-noise) discussions in 
debian-devel
 about this, and some previous concrete design discussion, but in 
all of
 the other, mostly unproductive threads on this topic, I've lost 
track of

 status or the current proposed approach.


The currently implemented approach is largely the same as what we
proposed and discussed publicly back in July
(https://lists.debian.org/debian-devel/2014/07/msg00611.html). It's
based on work by Steve Langasek, who did the groundwork to do the 
switch

on upgrades within one release cycle by splitting up the sysvinit
package and moving the contents into a new, non-essential 
sysvinit-core

package.

A summary of the changes:

1/ Introduction of a new, essential meta package named "init", which
   depends on systemd-sysv | sysvinit-core | upstart

2/ sysvinit became a transitional package, which is non-essential, and
   pre-depends on "init".

3/ Adjusting priorities of affected packages accordingly.

New installations
=
The new "init" package will ensure that systemd-sysv is installed as
default init on Linux and by demoting the priority of sysvinit and
sysvinit-core to optional those packages will not be installed 
anymore.


Upgrades

On upgrades, the old, essential sysvinit package will be replaced by 
the

new, non-essential sysvinit package which pulls in the new "init"
package which in turn makes sure systemd-sysv is installed.

In summary, on both new installations and upgrades, the default is
switched.

Upgrade safety measures
===
An important detail is, that on upgrades, we keep the sysvinit package
installed, which ships /lib/sysvinit/init. This makes it very easy to
boot using sysvinit, even if systemd is the default /sbin/init. We
proposed a patch for grub2 (https://bugs.debian.org/757298), which 
makes

this even more straightforward. Unfortunately this patch hasn't been
merged yet and we are still waiting for a reply from the maintainer.

One change is that we see there is a need for a check in postinst that
will look for common misconfigurations and potential errors and if so,
inform the user about those problems and how he can fix those or roll
back to sysvinit (which is basically as simple as running apt-get
install sysvinit-core). We'd like to ship those checks in a dedicated
script, which can be run by the user at any time.

So far, we believe that the best course of action is, to only show 
that
debconf prompt if potential problems are detected. This could be 
easily

changed though, to always show the debconf prompt on upgrades to raise
awareness and visibility of the change.

We believe it is a bad idea to stop changing to systemd on upgrades. 
One
of the reasons for this is we have the dependencies in place to 
actually

get upgrades and initial installations to behave as specified. If we
change how we want this done, somebody needs to sit down and do that
work again, testing all the various edge cases. Getting this right is
not trivial. Two weeks before the freeze is pretty late to start that
work.

Prior art
=
We also like to mention, that there is prior art regarding this
change. When we switched to dependency based booting in squeeze, this
was done on new installations as well as on upgrades.

 I would be particularly interested in your take on the analysis 
that Steve
 Langasek posted to the debian-devel thread on why listing 
systemd-shim as
 the first alternative dependency for libpam-systemd makes sense and 
should

 not cause any negative effects for systemd users.


In a steady state, this would probably be ok. However, we've so far 
seen

two instances of -shim breaking for systemd users
(https://bugs.debian.org/746242 and https://bugs.debian.org/765101), 
by

shipping outdated security policies. We are worried that this will
happen again on future updates of systemd.


Josh Triplett proposed a long term solution to the problem you point 
out here that will work across systemd upgrades. What are your thoughts 
on that solution? 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765101#38
We are also worried about it still having release critical bugs and 
the

feedback we are hearing from the desktop maintainers is that they see
bugs which are tracked down to bugs in -shim. We therefore don't 
believe

that is a good choice for desktop users.


Steve's argument is that choosing sysvinit-core over systemd-sysv 
should
automatically reflect on choosing systemd-shim over systemd-sysv. We 
do

not necessarily think this is the case and both decisions need to be
taken

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Ian Jackson]

Bdale Garbee writes ("Bug#765803: Status of prompting / notification on upgrade 
for init system switch?"):
> Ian Jackson  writes:
> >  4. So, if an existing installation has its init system switched, as a
> > result of upgrading or of installing packages, that is a bug
> > (unless it is not possible to retain the existing init system).
> 
> > The caveat in (4) avoids prejudging the results of the coupling
> > question which is the subject of the GR process at the moment.
> 
> I don't think it does so sufficiently to allow me to be in favor of this
> resolution.

Can you suggest some weaker text which would help ?

> I agree that we did not intend there to be some spontaneous move to
> transition all existing sysvinit users to systemd.

That is what is happening and it is how many people are interpreting
the TC resolution.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21574.57293.379463.659...@chiark.greenend.org.uk

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Bdale Garbee]

Ian Jackson  writes:

>  2. Normally when Debian changes the default provider of some service,
> this means that new installs get the new provider.  We do not
> transition existing installs to the new provider during upgrades,
> unless the old provider is being removed.

That's not strictly true.  Packages may not be removed, but the default
for various applications can and certainly does change on upgrades.  I'm
thinking of things like which gcc version is the default on a system.

>  3. The TC did not intend that our decision should extend to switching
> existing Debian GNU/Linux installations from sysvinit to systemd.
> Nor do we think that those users should be prompted to switch init
> system.

I agree that we did not intend there to be some spontaneous move to
transition all existing sysvinit users to systemd.

>  4. So, if an existing installation has its init system switched, as a
> result of upgrading or of installing packages, that is a bug
> (unless it is not possible to retain the existing init system).

> The caveat in (4) avoids prejudging the results of the coupling
> question which is the subject of the GR process at the moment.

I don't think it does so sufficiently to allow me to be in favor of this
resolution.

If we admit to the possibility that there might be a package with a
legitimate hard dependency on a specific init system other than the one
currently installed, a user who willingly chooses that package would be
within their rights to consider it a bug if their init system were *not*
changed.

So, to me, this all boils down to whether we think such a dependency
should be allowed to exist in the archive.  Given the apparent
inevitability of a GR, I'd rather we just wait and see how it turns out. 

Bdale


pgplEezrE9YdF.pgp
Description: PGP signature

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Russ Allbery]

Ian Jackson  writes:
> Russ Allbery writes:

>> Thanks, Tollef!  Okay, so there does appear to be a conflict here.  It
>> sounds like your primary technical concern, not addressed by Martin's
>> mail, is that getting the dependencies right to install systemd on
>> initial install but not upgrade to it are tricky and have a lot of
>> corner cases, and you feel like it's late in the release process to
>> make that change.

> That's not the impression I got from Tollef's mail.  I thought his
> concern was mostly bugs in systemd-shim.  Surely the question of
> the default can be addressed easily enough in the installer - it can
> just be told, explicitly, to install systemd.

It would be better to let Tollef speak for himself, so re-adding the
systemd mailing list, but I believe his message was addressing two
different issues: whether to switch init systems on upgrade, and the
dependencies on libpam-systemd (since I explicitly asked about that).  The
issue of bugs in systemd-shim came up in the latter context, and I replied
to that in that context.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnp571jh@hope.eyrie.org

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Ian Jackson]

Russ Allbery writes ("Bug#765803: Status of prompting / notification on upgrade 
for init system switch?"):
> Thanks, Tollef!  Okay, so there does appear to be a conflict here.  It
> sounds like your primary technical concern, not addressed by Martin's
> mail, is that getting the dependencies right to install systemd on initial
> install but not upgrade to it are tricky and have a lot of corner cases,
> and you feel like it's late in the release process to make that change.

That's not the impression I got from Tollef's mail.  I thought his
concern was mostly bugs in systemd-shim.  Surely the question of
the default can be addressed easily enough in the installer - it can
just be told, explicitly, to install systemd.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21574.40050.527334.10...@chiark.greenend.org.uk

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Russ Allbery]

Thanks, Tollef!  Okay, so there does appear to be a conflict here.  It
sounds like your primary technical concern, not addressed by Martin's
mail, is that getting the dependencies right to install systemd on initial
install but not upgrade to it are tricky and have a lot of corner cases,
and you feel like it's late in the release process to make that change.
(This is apart from the general feeling that users would be better off
with the default, which is more of a judgement call about policy.)

Is that a fair summary?

One specific point on the libpam-systemd issue:

Tollef Fog Heen  writes:

> In a steady state, this would probably be ok. However, we've so far seen
> two instances of -shim breaking for systemd users
> (https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by
> shipping outdated security policies. We are worried that this will
> happen again on future updates of systemd.

> We are also worried about it still having release critical bugs and the
> feedback we are hearing from the desktop maintainers is that they see
> bugs which are tracked down to bugs in -shim. We therefore don't believe
> that is a good choice for desktop users.

I don't particularly like this argument.  This is the reason why we should
fix bugs in systemd-shim and be sure that it's RC-free in the release, not
a reason to not install it unless those bugs can't be fixed.  In general,
we fix software that has bugs rather than avoid installing it, unless
those bugs aren't fixable.

I would even go so far as to say that it's good that we're exposing these
bugs now, during our release preparation process, so that they can be
fixed prior to jessie.  We need systemd-shim to work properly in jessie if
we can find the resources to do that work; we know that a lot of users
will want to continue using sysvinit for jessie.  systemd is a big change,
and, even if one thinks that the same thing that happpened with udev will
happen to it in the long run, as with udev we need to support both
configurations at least until one of them naturally fades away (if that
happens).  And, so far, it looks like the resources to make systemd-shim
work will be available.

> Steve's argument is that choosing sysvinit-core over systemd-sysv should
> automatically reflect on choosing systemd-shim over systemd-sysv. We do
> not necessarily think this is the case and both decisions need to be
> taken on their own.

I thought the argument was that listing systemd-shim first makes no
difference except in the case where someone does not currently have
systemd installed at all.  In other words, both of those decisions can
still be taken on their own, and that dependency order will preserve the
existing state.  Did I get that wrong?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lho971zf@hope.eyrie.org

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Tollef Fog Heen]

]] Russ Allbery

Hello Russ, CTTE,

> Hello, systemd maintainers.
> 
> We (the Technical Committee) have received a request to override a
> maintainer decision around whether systems are switched from sysvinit to
> systemd on upgrade.  However, it's not clear to me that an actual decision
> has been made that we would need to override.
> 
> There have been multiple (fairly high-noise) discussions in debian-devel
> about this, and some previous concrete design discussion, but in all of
> the other, mostly unproductive threads on this topic, I've lost track of
> status or the current proposed approach.

The currently implemented approach is largely the same as what we
proposed and discussed publicly back in July
(https://lists.debian.org/debian-devel/2014/07/msg00611.html). It's
based on work by Steve Langasek, who did the groundwork to do the switch
on upgrades within one release cycle by splitting up the sysvinit
package and moving the contents into a new, non-essential sysvinit-core
package.

A summary of the changes:

1/ Introduction of a new, essential meta package named "init", which
   depends on systemd-sysv | sysvinit-core | upstart

2/ sysvinit became a transitional package, which is non-essential, and
   pre-depends on "init".

3/ Adjusting priorities of affected packages accordingly.

New installations
=
The new "init" package will ensure that systemd-sysv is installed as
default init on Linux and by demoting the priority of sysvinit and
sysvinit-core to optional those packages will not be installed anymore.

Upgrades

On upgrades, the old, essential sysvinit package will be replaced by the
new, non-essential sysvinit package which pulls in the new "init"
package which in turn makes sure systemd-sysv is installed.

In summary, on both new installations and upgrades, the default is
switched.

Upgrade safety measures
===
An important detail is, that on upgrades, we keep the sysvinit package
installed, which ships /lib/sysvinit/init. This makes it very easy to
boot using sysvinit, even if systemd is the default /sbin/init. We
proposed a patch for grub2 (https://bugs.debian.org/757298), which makes
this even more straightforward. Unfortunately this patch hasn't been
merged yet and we are still waiting for a reply from the maintainer.

One change is that we see there is a need for a check in postinst that
will look for common misconfigurations and potential errors and if so,
inform the user about those problems and how he can fix those or roll
back to sysvinit (which is basically as simple as running apt-get
install sysvinit-core). We'd like to ship those checks in a dedicated
script, which can be run by the user at any time.

So far, we believe that the best course of action is, to only show that
debconf prompt if potential problems are detected. This could be easily
changed though, to always show the debconf prompt on upgrades to raise
awareness and visibility of the change.

We believe it is a bad idea to stop changing to systemd on upgrades. One
of the reasons for this is we have the dependencies in place to actually
get upgrades and initial installations to behave as specified. If we
change how we want this done, somebody needs to sit down and do that
work again, testing all the various edge cases. Getting this right is
not trivial. Two weeks before the freeze is pretty late to start that
work.

Prior art
=
We also like to mention, that there is prior art regarding this
change. When we switched to dependency based booting in squeeze, this
was done on new installations as well as on upgrades.

> I would be particularly interested in your take on the analysis that Steve
> Langasek posted to the debian-devel thread on why listing systemd-shim as
> the first alternative dependency for libpam-systemd makes sense and should
> not cause any negative effects for systemd users.

In a steady state, this would probably be ok. However, we've so far seen
two instances of -shim breaking for systemd users
(https://bugs.debian.org/746242 and https://bugs.debian.org/765101), by
shipping outdated security policies. We are worried that this will
happen again on future updates of systemd.

We are also worried about it still having release critical bugs and the
feedback we are hearing from the desktop maintainers is that they see
bugs which are tracked down to bugs in -shim. We therefore don't believe
that is a good choice for desktop users.

Steve's argument is that choosing sysvinit-core over systemd-sysv should
automatically reflect on choosing systemd-shim over systemd-sysv. We do
not necessarily think this is the case and both decisions need to be
taken on their own.

-- 
Tollef Fog Heen, on behalf of the systemd team
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Uoti Urpala]

On Mon, 20 Oct 2014 10:06:31 -0400 Martin Pitt  wrote:
> I'll leave this to the Debian maintainers, as I'm mostly responsible
> for the Ubuntu side, haven't really discussed this with the two
> Michaels/Tollef/Marco, and I don't feel qualified to speak for the
> Debian systemd team.
> 
> My personal opinion: Given how close we are to the release and how
> many regression reports we still get, it seems prudent to not change
> the currently running init systems for upgrades for Jessie yet, but
> only set up systemd for new installs. I know this is not really in the
> spirit of the TC decision to make systemd the default init system, but
> at this point in time it might be the pragmatic compromise.
> 
> The systemd package gets literally swamped with bug reports (of all
> kinds of usefulness/quality), and there's simply not enough
> maintainers to keep up with the flood. Many of those are indeed not
> actual bugs in systemd, but bugs in other packages, local

That "swamped with bug reports" does not match my impression of reading
the systemd packaging list. As far as I can tell, this is not the view
of the Debian maintainers either.

My impression from the bug reports is that systemd-shim does not work
particularly reliably. So automatically installing systemd-shim does not
seem any safer than automatically installing systemd from the view of
avoiding breaking old systems.


> The other direction (running sysvinit or upstart with -shim) has not
> been so unproblematic though, as systemd-shim's bug list shows. This
> definitively needs some love, but then again we've run this for a fair
> while in Ubuntu (even in our 14.04 LTS) without too many problems. So
> my feeling is that we can certainly stabilize -shim by the jessie
> release. (We need to do that anyway, as we need to support sysvinit
> regardless of what we do on upgrades/new installs.)

Is there some reason to believe that there would be _more_ success with
this than with resolving the remaining integration issues with systemd?
And shouldn't work on the latter be higher priority?


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413908276.29980.1.ca...@pp1.inet.fi

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Ansgar Burchardt]

Hi Ian,

On 10/21/2014 05:44 PM, Ian Jackson wrote:
> I think the principle, of whether this switch should be made
> automatic, ought to be addressed separately, and should be regarded as
> a question of overlapping jurisdictions.  We can't have different
> maintainers fighting over init on users' systems by publishing
> packages with dependencies which result in their preferred setup.

What gives you the impression that different maintainers fight over
providing init? I have not seen that happening.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54468897.2080...@43-1.org

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Ian Jackson]

Russ Allbery writes ("Re: Bug#765803: Status of prompting / notification on 
upgrade for init system switch?"):
> If you're proposing this as a resolution of #765803, that's fine.

I'm not sure I follow.  You think it would be proper for the TC to
pass a resolution along the lines of the one I proposed, but only if
it's a resolution to #765803 rather than one of the other bug
reports ?  That's fine, I don't care precisely what subset of the bugs
we regard it as closing.

> It may be that I just misunderstood the context of your proposal, given
> that, now that I re-read it, it sounds like you were aiming for a
> resolution of #765803 all along.  In which case I'm just confused, and
> what I'm arguing about isn't even what you were intending.  :)

Yes, I was aiming for a resolution of #765803 and #762194 all along.
I have sent my mail to just #765803 because that's where most of the
discussion happened.  Passing a resolution along the lines I proposed
does not directly dispose of #746578, but it would inform our
discussion of that issue.

>  I haven't decided if that's something I'd agree with yet or not.

I think we need to get on with this.  This question was raised in the
context of #746578 in May and #762194 in September.  I don't think the
question is very complicated, even in the absence of Martin Pitt's
email.

So I hereby formally propose the following draft:

 -8<-

 1. In February the TC decided that the default init system for Linux
in Debian jessie would be systemd.  We have been asked what this
should mean for systems being upgraded from earlier Debian
releases:

Should existing installs be automatically switched to systemd
(#762194) ?  Should users be prompted (#765803) ?

 2. Normally when Debian changes the default provider of some service,
this means that new installs get the new provider.  We do not
transition existing installs to the new provider during upgrades,
unless the old provider is being removed.

 3. The TC does not feel that our decision should extend to switching
existing Debian GNU/Linux installations from sysvinit to systemd.
Nor do we think that those users should be prompted to switch init
system.

 4. So, if an existing installation has its init system switched, as a
result of upgrading or of installing packages, that is a bug
(unless it is not possible to retain the existing init system).

 -8<-

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21574.34515.624973.911...@chiark.greenend.org.uk

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Russ Allbery]

Ian Jackson  writes:

> Tollef Fog Heen claimed in
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#134
> that there is consensus on debian-devel in favour of the switch.

That was some time ago, and Martin has expressed a different opinion.  I
think the systemd team should have a chance to talk this over internally
and see if they still feel that this is the right choice for Debian.  (I
know that we're on a bit of a schedule here due to the freeze.)

> In earlier messages you have framed some of these bugs as requests to
> overrule particular maintainers, whose packages had dependencies which
> were causing this switch.

> I think the principle, of whether this switch should be made
> automatic, ought to be addressed separately, and should be regarded as
> a question of overlapping jurisdictions.  We can't have different
> maintainers fighting over init on users' systems by publishing
> packages with dependencies which result in their preferred setup.

The primary question that's obviously a maintainer override is the order
of dependencies in libpam-systemd, and I still think we can reach a
consensus there without the TC needing to rule on something.

> I think we should therefore issue a set of general guidance along the
> lines of the draft I just posted.

I believe it would be a mistake to start doing that without giving the
systemd maintainers a chance to discuss Martin's message and the overall
issue, and to decide if there's actually a conflict here.

> Your objection that you feel we hadn't decided at the time could be
> addressed by altering para 3 of my draft to read:

>   3. The TC does not feel that our decision should extend to switching
>  existing Debian GNU/Linux installations from sysvinit to systemd.
>  Nor do we think that those users should be prompted to switch init
>  system.

If you're proposing this as a resolution of #765803, that's fine.  I
haven't decided if that's something I'd agree with yet or not.

However, I was under the impression that you were proposing that we issue
a resolution, independent of #765803, that clarifies our February
decision.  I was trying to say that I think that might be a reasonable
course of action, but it would need to just say that our February decision
didn't express an opinion about upgrades.  That's how I understood it, at
least; the other members of the TC can obviously weigh in if they
disagree.  In *that* context, paragraph 3 (and 4) of your proposal are
obviously out of place and shouldn't be included.

It may be that I just misunderstood the context of your proposal, given
that, now that I re-read it, it sounds like you were aiming for a
resolution of #765803 all along.  In which case I'm just confused, and
what I'm arguing about isn't even what you were intending.  :)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oat58lae@hope.eyrie.org

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Ian Jackson]

Russ Allbery writes ("Re: Bug#765803: Status of prompting / notification on 
upgrade for init system switch?"):
> This implies that we had decided not to change init systems on upgrade.  I
> don't believe that's correct.  I didn't express an opinion on it one way
> or another and intended to leave that for further discussion within the
> project.

We have been asked to decide on this question in #746578 even if you
don't think my own referral in #762194 is good enough.  It comes up in
#765803 too, although the question there is phrased differently.

>   it's not clear to me yet whether the TC even has actionable
> jurisdiction (in that there may not even be a conflict).

Svante Signell and I have clearly said that we think users should not
be switched automatically.

Tollef Fog Heen claimed in
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746578#134
that there is consensus on debian-devel in favour of the switch.


In earlier messages you have framed some of these bugs as requests to
overrule particular maintainers, whose packages had dependencies which
were causing this switch.

I think the principle, of whether this switch should be made
automatic, ought to be addressed separately, and should be regarded as
a question of overlapping jurisdictions.  We can't have different
maintainers fighting over init on users' systems by publishing
packages with dependencies which result in their preferred setup.

I think we should therefore issue a set of general guidance along the
lines of the draft I just posted.

If that guidance has technical consequences for the dependencies in
particular packages, and the maintainers do not agree, then that might
involve the TC overruling a particular maintainer to ensure that the
general principle is implemented.


Your objection that you feel we hadn't decided at the time could be
addressed by altering para 3 of my draft to read:

  3. The TC does not feel that our decision should extend to switching
 existing Debian GNU/Linux installations from sysvinit to systemd.
 Nor do we think that those users should be prompted to switch init
 system.


Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21574.32635.815548.602...@chiark.greenend.org.uk

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Russ Allbery]

Ian Jackson  writes:

> I think it would be helpful to write this up as a resolution.  How
> about:

>  -8<-

>  1. In February the TC decided that the default init system for Linux
> in Debian jessie would be systemd.  We have been asked what this
> should mean for systems being upgraded from earlier Debian
> releases:

> Should existing installs be automatically switched to systemd ?
> Should users be prompted ?

>  2. Normally when Debian changes the default provider of some service,
> this means that new installs get the new provider.  We do not
> transition existing installs to the new provider during upgrades,
> unless the old provider is being removed.

>  3. The TC did not intend that our decision should extend to switching
> existing Debian GNU/Linux installations from sysvinit to systemd.
> Nor do we think that those users should be prompted to switch init
> system.

>  4. So, if an existing installation has its init system switched, as a
> result of upgrading or of installing packages, that is a bug
> (unless it is not possible to retain the existing init system).

This implies that we had decided not to change init systems on upgrade.  I
don't believe that's correct.  I didn't express an opinion on it one way
or another and intended to leave that for further discussion within the
project.

I'm happy to vote for a resolution that clarifies that our previous
decision expressed no opinion on whether the init system should be changed
on upgrade.  Whether it should be upgraded is a question that has not come
before us until just now, and therefore clearly wasn't something we
decided last February.  If we need to decide that, we should do it in the
context of the current bug, not in the context of last February, and it's
not clear to me yet whether the TC even has actionable jurisdiction (in
that there may not even be a conflict).

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738aha191@hope.eyrie.org

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Ian Jackson]

Bdale Garbee writes ("Bug#765803: Status of prompting / notification on upgrade 
for init system switch?"):
> Russ Allbery  writes:
> > I think "default" is about what we install with fresh installs.
> > That's consistent with the other examples you list, where we've picked
> > a default.
> 
> I agree.

I think it would be helpful to write this up as a resolution.  How
about:

 -8<-

 1. In February the TC decided that the default init system for Linux
in Debian jessie would be systemd.  We have been asked what this
should mean for systems being upgraded from earlier Debian
releases:

Should existing installs be automatically switched to systemd ?
Should users be prompted ?

 2. Normally when Debian changes the default provider of some service,
this means that new installs get the new provider.  We do not
transition existing installs to the new provider during upgrades,
unless the old provider is being removed.

 3. The TC did not intend that our decision should extend to switching
existing Debian GNU/Linux installations from sysvinit to systemd.
Nor do we think that those users should be prompted to switch init
system.

 4. So, if an existing installation has its init system switched, as a
result of upgrading or of installing packages, that is a bug
(unless it is not possible to retain the existing init system).

 -8<-

The caveat in (4) avoids prejudging the results of the coupling
question which is the subject of the GR process at the moment.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21574.29282.239270.556...@chiark.greenend.org.uk

Bug#765803: Status of prompting / notification on upgrade for init system switch?

[Bdale Garbee]

Russ Allbery  writes:

> I think "default" is about what we install with fresh installs.
> That's consistent with the other examples you list, where we've picked
> a default.

I agree.

Bdale


pgpbspOmI0C3L.pgp
Description: PGP signature