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

[Tollef Fog Heen]

]] Russ Allbery 

> Tollef Fog Heen  writes:
> > ]] 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?
> 
> > Yes.
> 
> Thanks!  I do think that argues for a clear testing plan if someone
> proposes a change in how the dependencies are structured to avoid
> upgrading to it.

Right.  I think the right approach is to upgrade unless the user vetoes
it, but that's something reasonable people can disagree about.  (I've
come around to the idea that we should prompt on upgrades, as much as I
loathe prompts.)

> >> 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.
> 
> > Based on that argument, we should install as much software as possible
> > on users' desktops, to ensure we expose as many weird interaction bugs
> > as possible.  I don't actually believe this is what you mean, so if you
> > want to EXPN a bit, please do.
> 
> Right, my point here is that I don't think we should choose libpam-systemd
> dependency order purely on the basis of perception of how many bugs there
> currently are in the native systemd support versions the systemd-shim
> support.  That's partly a special case to this particular transition:
> there is obviously huge controversy over which approach is better for the
> average user, and both "sides" feel like the other program is obviously
> more buggy.

I can agree with that.  The other argument for having libpam-systemd
depend on systemd-sysv | systemd-shim rather than the other way around
is that systemd-sysv is the default (in Debian), the recommended (by the
maintainer) and the most well-tested fulfiller of the dependency.

> systemd-shim working properly is probably going to be RC for jessie.  I
> don't think there's any way to avoid that unless it's so bad that the
> people who are working on it say that there's no way that it can be stable
> for jessie and give up on that.  I don't think that's very likely.

No disagreements from me here.

> So avoiding it in dependencies because it has RC bugs doesn't, in that
> sense, help us get jessie out the door faster, because I doubt we're going
> to release jessie until it's in a reasonable state anyway.

If it makes you happier, we can avoid it as the preferred solution for
the reasons listed above.  I'm not picky. :-)

> Maybe I'm analyzing this wrong and it's more likely than I think that
> people are going to give up on getting systemd-shim working, or the
> project is going to be willing to release without it working, but I'm
> pretty dubious.

I'm less concerned about whether -shim works or not (since my main
concern is whether systemd itself works correctly or not).  I'm more
concerned about it breaking things for people who are using systemd
(directly or indirectly).

-- 
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/87h9ykfh7c@aexonyam.err.no

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

[Tollef Fog Heen]

]] Tollef Fog Heen 

> ]] Martin Pitt 
> 
> > Tollef Fog Heen [2014-10-21 19:19 +0200]:
> > > > 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.
> > 
> > 8-4 now eliminates the copied d-bus policy entirely. This was by and
> > large a leftover when Ubuntu had the split systemd-services, and other
> > than that there was one remaining delta in the policy which we
> > discussed yesterday and found to be unnecessary (and detrimental).
> 
> That is good to hear.  I'm hoping you're right there aren't any other
> ways for it to regress for non-shim users.

I just became aware of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767468 .  Not directly
a shim bug, but cgmanager is pulled in by shim.  (I have not done any
analysis on the bug myself apart from reading it, but it looks
reasonable.)

-- 
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/87lhnwfr9x@aexonyam.err.no

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

[Colin Watson]

On Tue, Oct 21, 2014 at 07:19:32PM +0200, Tollef Fog Heen wrote:
> 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.

That's my fault, sorry.  I've been pretty swamped in a number of ways
recently and took longer than I should have done to realise what was
going on; but I'm now taking steps to deal with it (as per my blog).
I'll make sure that some variant of that patch gets into jessie, since
it seems like a reasonable change regardless of what else is decided
here.

-- 
Colin Watson   [cjwat...@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/20141030142309.gb3...@riva.ucam.org

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

[Josh Triplett]

On Thu, Oct 23, 2014 at 08:49:20PM -0700, Cameron Norman wrote:
> On Thu, Oct 23, 2014 at 8:13 PM, Josh Triplett  wrote:
> > On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote:
> >> > "Josh" == Josh Triplett  writes:
> >>
> >> Josh> - It can't check for generated lines for serial consoles or
> >> Josh> similar; finish-install can generate various additional
> >> Josh> inittab lines, which the check should include.
> >>
> >> Since when did systemd actually handle these correctly?
> >> I've generally found that systemd will give me a serial console only if
> >> the kernel console is that serial console.
> >> I've found that if I manually enable a serial console but have the
> >> kernel console  go somewhere else, I end up with a system I cannot log
> >> into when I  upgrade to systemd.
> >> This has been no end of frustration and I hope that your check correctly
> >> prompts in this case even when  the line I generate is exactly the
> >> same as a line generated by the installer.
> >>
> >> If it's gotten better and I'd actually get a console in that case,
> >> that's of course fine too.
> >> It should either let me know I'm about to hurt myself or work:-)
> >> Either behavior is fine.
> >
> > TTBOMK, you'll automatically get a console on a serial port in a few
> > cases:
> >
> > - If the kernel console points there (console=ttyS0); note that this
> >   works even if you change that console.
> >
> > - If the console is identified as a default system console (works for
> >   virtual machine serial ports, and for systems with unusually named
> >   standard console serial ports).
> >
> > See systemd-getty-generator.
> >
> > In other cases, you have to manually "systemctl enable
> > serial-getty@ttyX.service".
> >
> > I wonder if it might make sense to do a one-time migration that parses
> > /etc/inittab, looks for serial console getty lines, and enables
> > serial-getty@.service for any consoles it finds gettys for?
> 
> If you are going to the work of parsing it all, would it not make
> sense to make a systemd generator out of it?

I didn't suggest attempting to handle all of inittab, only serial
console gettys.  A generator would have to deal with several additional
issues that a one-time migration of specific bits would not.

Almost everything in the default inittab duplicates systemd
functionality, and it would not make sense to translate those lines
across with a generator: default runlevel, sysinit, single-user-mode,
invoking /etc/init.d/rc, invoking sulogin, the default ctrl-alt-del
handling, the powerfail handling, and the default gettys on ttys.
Keyboard requests could make sense to translate to
kbrequest.target.wants units.  Modified ctrl-alt-del or powerfail lines
might or might not make sense to translate.  Any runlevel-specific
service that isn't a getty or /etc/init.d/rc *might* make sense to
translate.  And it isn't at all obvious how to handle services or gettys
specified for non-default runlevels; starting them could be dangerous.
So, any working inittab generator would have a pile of special cases to
skip over parts of the default inittab, which seems complex,
error-prone, and not particularly user-friendly.

Instead, I think it makes sense to scan inittab for serial console
lines, possibly limited to only those that run in the default runlevel.
Even that could potentially cause problems, but nonetheless it seems
worth doing to transparently work on systems where the user has a serial
console that for some reason isn't specified as a console on the kernel
command line.

- Josh Triplett


-- 
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/20141027144303.GA1984@jtriplet-mobl1

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

[Steve Langasek]

On Fri, Oct 24, 2014 at 01:31:55PM +0200, Tollef Fog Heen wrote:
> > 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.

> I don't think the necessary manpower to fix those bugs is available.  If
> so, why are we now then at ten days before the freeze with bugs that
> were made release critical in -shim more than a month ago with no
> subsequent response from the maintainer?

Is that bug #759745 which was assigned to systemd-shim 8 days ago and
appears to be a duplicate of bug #757348, or bug #756076 which was marked
*resolved* on September 10 and was reopened, with a subsequent history that
in no way explains why it's been marked as "grave"?

Regardless, "I don't think the RC bugs will be fixed" is still not an excuse
for enforcing a different set of bugs via the dependencies of
libpam-systemd.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@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/20141025071504.gd15...@virgil.dodds.net

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

[Tollef Fog Heen]

]] Martin Pitt 

> Tollef Fog Heen [2014-10-21 19:19 +0200]:
> > > 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.
> 
> 8-4 now eliminates the copied d-bus policy entirely. This was by and
> large a leftover when Ubuntu had the split systemd-services, and other
> than that there was one remaining delta in the policy which we
> discussed yesterday and found to be unnecessary (and detrimental).

That is good to hear.  I'm hoping you're right there aren't any other
ways for it to regress for non-shim users.

> Of course there are still a lot of bug reports *in* -shim, i. e. which
> hit when you run with sysvinit or upstart. But that's the opposite
> case of what you were concerned about, right?

Indeed.

-- 
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/87fvedfdea@xoog.err.no

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

[Russ Allbery]

I think you got bit by the Mail-Followup-To and your messages didn't make
it to the CTTE bug.

Tollef Fog Heen  writes:
> ]] 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?

> Yes.

Thanks!  I do think that argues for a clear testing plan if someone
proposes a change in how the dependencies are structured to avoid
upgrading to it.

>> 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.

> Based on that argument, we should install as much software as possible
> on users' desktops, to ensure we expose as many weird interaction bugs
> as possible.  I don't actually believe this is what you mean, so if you
> want to EXPN a bit, please do.

Right, my point here is that I don't think we should choose libpam-systemd
dependency order purely on the basis of perception of how many bugs there
currently are in the native systemd support versions the systemd-shim
support.  That's partly a special case to this particular transition:
there is obviously huge controversy over which approach is better for the
average user, and both "sides" feel like the other program is obviously
more buggy.

Rather, I think we should decide whether we're upgrading users by default
or not upgrading users by default, on the basis of the broader situation
with both stacks plus the various social aspects to this whole argument,
and then choose dependencies that cause the fewest problems for the most
users given the background of that decision.

systemd-shim working properly is probably going to be RC for jessie.  I
don't think there's any way to avoid that unless it's so bad that the
people who are working on it say that there's no way that it can be stable
for jessie and give up on that.  I don't think that's very likely.

So avoiding it in dependencies because it has RC bugs doesn't, in that
sense, help us get jessie out the door faster, because I doubt we're going
to release jessie until it's in a reasonable state anyway.

Maybe I'm analyzing this wrong and it's more likely than I think that
people are going to give up on getting systemd-shim working, or the
project is going to be willing to release without it working, but I'm
pretty dubious.

-- 
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/87egtxcx3h@hope.eyrie.org

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

[Tollef Fog Heen]

]] 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.

And by «the installer», you mean d-i, vmdebootstrap, ganeti, libvirt,
pbuilder, schroot, rootstrap and fai, to list a few ways of installing
Debian?

It's less work to just document how to keep sysvinit in the release
notes, something I surely hope we're going to do anyway.

-- 
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/m24muthfdu@rahvafeir.err.no

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

[Tollef Fog Heen]

]] 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?

Yes.

> 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.

Based on that argument, we should install as much software as possible
on users' desktops, to ensure we expose as many weird interaction bugs
as possible.  I don't actually believe this is what you mean, so if you
want to EXPN a bit, please do.

> 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.

I don't think the necessary manpower to fix those bugs is available.  If
so, why are we now then at ten days before the freeze with bugs that
were made release critical in -shim more than a month ago with no
subsequent response from the maintainer?

> > 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?

Not sure, maybe Michael can comment on this bit?

-- 
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/m261f9hff8@rahvafeir.err.no

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

[Cameron Norman]

On Thu, Oct 23, 2014 at 8:13 PM, Josh Triplett  wrote:
> On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote:
>> > "Josh" == Josh Triplett  writes:
>>
>> Josh> - It can't check for generated lines for serial consoles or
>> Josh> similar; finish-install can generate various additional
>> Josh> inittab lines, which the check should include.
>>
>> Since when did systemd actually handle these correctly?
>> I've generally found that systemd will give me a serial console only if
>> the kernel console is that serial console.
>> I've found that if I manually enable a serial console but have the
>> kernel console  go somewhere else, I end up with a system I cannot log
>> into when I  upgrade to systemd.
>> This has been no end of frustration and I hope that your check correctly
>> prompts in this case even when  the line I generate is exactly the
>> same as a line generated by the installer.
>>
>> If it's gotten better and I'd actually get a console in that case,
>> that's of course fine too.
>> It should either let me know I'm about to hurt myself or work:-)
>> Either behavior is fine.
>
> TTBOMK, you'll automatically get a console on a serial port in a few
> cases:
>
> - If the kernel console points there (console=ttyS0); note that this
>   works even if you change that console.
>
> - If the console is identified as a default system console (works for
>   virtual machine serial ports, and for systems with unusually named
>   standard console serial ports).
>
> See systemd-getty-generator.
>
> In other cases, you have to manually "systemctl enable
> serial-getty@ttyX.service".
>
> I wonder if it might make sense to do a one-time migration that parses
> /etc/inittab, looks for serial console getty lines, and enables
> serial-getty@.service for any consoles it finds gettys for?

If you are going to the work of parsing it all, would it not make
sense to make a systemd generator out of it?

--
Cameron Norman


-- 
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/CALZWFRJsMWVXXx5iz=kstt82dn3ovddc9xrhn8asqon-wvk...@mail.gmail.com

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

[Josh Triplett]

On Thu, Oct 23, 2014 at 10:21:27PM -0400, Sam Hartman wrote:
> > "Josh" == Josh Triplett  writes:
> 
> Josh> - It can't check for generated lines for serial consoles or
> Josh> similar; finish-install can generate various additional
> Josh> inittab lines, which the check should include.
> 
> Since when did systemd actually handle these correctly?
> I've generally found that systemd will give me a serial console only if
> the kernel console is that serial console.
> I've found that if I manually enable a serial console but have the
> kernel console  go somewhere else, I end up with a system I cannot log
> into when I  upgrade to systemd.
> This has been no end of frustration and I hope that your check correctly
> prompts in this case even when  the line I generate is exactly the
> same as a line generated by the installer.
> 
> If it's gotten better and I'd actually get a console in that case,
> that's of course fine too.
> It should either let me know I'm about to hurt myself or work:-)
> Either behavior is fine.

TTBOMK, you'll automatically get a console on a serial port in a few
cases:

- If the kernel console points there (console=ttyS0); note that this
  works even if you change that console.

- If the console is identified as a default system console (works for
  virtual machine serial ports, and for systems with unusually named
  standard console serial ports).

See systemd-getty-generator.

In other cases, you have to manually "systemctl enable
serial-getty@ttyX.service".

I wonder if it might make sense to do a one-time migration that parses
/etc/inittab, looks for serial console getty lines, and enables
serial-getty@.service for any consoles it finds gettys for?

- Josh Triplett


-- 
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/20141024031327.GA7879@thin

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

[Sam Hartman]

> "Josh" == Josh Triplett  writes:

Josh> - It can't check for generated lines for serial consoles or
Josh> similar; finish-install can generate various additional
Josh> inittab lines, which the check should include.

Since when did systemd actually handle these correctly?
I've generally found that systemd will give me a serial console only if
the kernel console is that serial console.
I've found that if I manually enable a serial console but have the
kernel console  go somewhere else, I end up with a system I cannot log
into when I  upgrade to systemd.
This has been no end of frustration and I hope that your check correctly
prompts in this case even when  the line I generate is exactly the
same as a line generated by the installer.

If it's gotten better and I'd actually get a console in that case,
that's of course fine too.
It should either let me know I'm about to hurt myself or work:-)
Either behavior is fine.


-- 
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/tslbnp2p5qw@mit.edu

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

[Martin Pitt]

Tollef Fog Heen [2014-10-21 19:19 +0200]:
> > 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.

8-4 now eliminates the copied d-bus policy entirely. This was by and
large a leftover when Ubuntu had the split systemd-services, and other
than that there was one remaining delta in the policy which we
discussed yesterday and found to be unnecessary (and detrimental).

AFAICS this was the only potential cause of regression of having
systemd-shim installed when running systemd as pid 1, and I'm glad
it's gone now. So 8-4 should now indeed be completely inert in that
case.

Of course there are still a lot of bug reports *in* -shim, i. e. which
hit when you run with sysvinit or upstart. But that's the opposite
case of what you were concerned about, right?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.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/20141022150222.ge31...@piware.de

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

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

[Russ Allbery]

Ian Jackson  writes:

> I don't think the TC decision should be read as mandating that existing
> installations should be switched when upgrading from wheezy.  As I have
> said, we (Debian) do not usually change the user's existing MTA, cron
> daemon, webserver, desktop, inetd, etc. etc. etc. when we change the
> default.  I don't think this is any different.

I agree that previous TC decisions don't say anything one way or the other
about whether systems should have their init systems changed on upgrade.
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.

> The question of whether this should be done is already with the TC.

However, if the systemd maintainers end up agreeing with Martin, I think
that means there is no conflict and nothing that the TC needs to rule on.

-- 
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/87ppdm8xit@hope.eyrie.org

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

[Ian Jackson]

Martin Pitt writes ("Bug#765803: Status of prompting / notification on upgrade 
for init system switch?"):
> 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.

I don't think the TC decision should be read as mandating that
existing installations should be switched when upgrading from wheezy.
As I have said, we (Debian) do not usually change the user's existing
MTA, cron daemon, webserver, desktop, inetd, etc. etc. etc. when we
change the default.  I don't think this is any different.

The question of whether this should be done is already with the TC.

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/21573.16345.455278.654...@chiark.greenend.org.uk

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

[Martin Pitt]

Hello Russ,

Russ Allbery [2014-10-18 20:59 -0700]:
> When one of you has a chance, could you update this bug with the current
> thinking around how to handle upgrades

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
misconfiguration, or mere misunderstanding, but a fair amount *are*
bugs in our integration (for the release it doesn't matter that much
whether they are in systemd itself or other packages).

The one thing that I'd really like to avoid is interactive prompting.
As much heat as the init system debate produced, from an user's POV
it's pretty much a tempest in a teapot. Quite frankly, as a user
I don't care that much about init systems, I just want my system to
boot and "apt install mysql" to DTRT. Moreso, do we really expect a
user to make this decision on upgrades? Look how hard it was even for
us as DDs or the TC to make an informed decision -- I really don't
want to push this to the user:

 [ ] Install init system A (may degrade some things)
 [ ] Install init system B (may break some things)

IMHO it's a distro's job to make this qualified decision for the user
based on which system he upgrades or installs.

> around the ordering of dependencies in libpam-systemd, and some of
> the other ideas (such as attempting to detect systems with
> /etc/inittab configuration or init scripts that don't follow
> systemd's assumptions) raised in those threads?

I haven't looked at those in detail. It's great to see that people
work on such heuristics for upgrades, but TBH it always takes a while
to stabilize those.

> 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.

As https://bugs.debian.org/765101 showed, installing systemd-shim has
not always been entirely inert/regression free under systemd as pid 1,
but to be fair this has been the only bug of that kind ever, and
there's a better solution proposed in that bug which will make this
never happen again.

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.)

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature

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

[Josh Triplett]

On Sun, 19 Oct 2014 21:10:10 +1100 Stuart Prescott  wrote:
> > inittab_unusual_lines="$(
> > grep '^[^#]' /etc/inittab |
> > while read line ; do
> > case "$line" in
> > 'id:2:initdefault:') ;;
> [...]
> 
> I wonder if it would just be easier to look at the md5sum of the file and 
> compare it to the md5sum of the inittab that was shipped in various releases 
> -- that's a fairly idiomatic approach to dealing with config files that 
> changed.

I considered that approach, but that has two issues:

- It doesn't take into account inittab files that have a mixture of
  lines from the inittab files of multiple releases, all of which are
  supported.  The approach I used can include lines from any number of
  inittab variations.

- It can't check for generated lines for serial consoles or similar;
  finish-install can generate various additional inittab lines, which
  the check should include.

- It unnecessarily prompts even if only comments or whitespace have been
  edited.

> > modified_initscripts="$(
> > grep -lE '^/etc/init\.d/' /var/lib/dpkg/info/*.conffiles |
> > xargs basename -s '.conffiles' |
> > xargs dpkg -V |
> > grep '^..5.. c /etc/init\.d/' |
> > cut -d' ' -f3
> > )"
> 
> For testing for modified init scripts, see also #760897 -- note that dpkg -V 
> requires jessie's dpkg (it is not available in wheezy). For some upgrades 
> between releases, we have advocated that people upgrade dpkg and apt first 
> and 
> then upgrade to the new release using the new versions of the tools but this 
> is far from idiot proof. There's a persistent expectation that just doing a 
> dist-upgrade should be enough and we see day-in-day-out that people do *not* 
> read the release notes.

Gah, I didn't realize that dpkg -V didn't exist in wheezy.  The package
with this check in its init script could have a Pre-Depends on jessie's
dpkg, which would solve the problem, but that may or may not be
desirable.

Based on the code from 760897, here's a version that should work with
wheezy's dpkg:

modified_initscripts="$(
dpkg-query --show -f'${Conffiles}' |
sed 's, /,\n/,g' |
sed -n '/^\/etc\/init\.d\//s/^\([^ ]*\) \(.*\)$/\2 \1/p' |
md5sum --quiet -c 2>/dev/null |
cut -d: -f1
)"

(Note that md5sum exits with non-zero if any of the checksums fail, but
since it isn't the last thing in the pipe, that doesn't actually matter
here.)

- Josh Triplett


-- 
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/20141020031036.GA21941@thin

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

[Stuart Prescott]

Hi Josh,

> inittab_unusual_lines="$(
> grep '^[^#]' /etc/inittab |
> while read line ; do
> case "$line" in
> 'id:2:initdefault:') ;;
[...]

I wonder if it would just be easier to look at the md5sum of the file and 
compare it to the md5sum of the inittab that was shipped in various releases 
-- that's a fairly idiomatic approach to dealing with config files that 
changed.

> modified_initscripts="$(
> grep -lE '^/etc/init\.d/' /var/lib/dpkg/info/*.conffiles |
> xargs basename -s '.conffiles' |
> xargs dpkg -V |
> grep '^..5.. c /etc/init\.d/' |
> cut -d' ' -f3
> )"

For testing for modified init scripts, see also #760897 -- note that dpkg -V 
requires jessie's dpkg (it is not available in wheezy). For some upgrades 
between releases, we have advocated that people upgrade dpkg and apt first and 
then upgrade to the new release using the new versions of the tools but this 
is far from idiot proof. There's a persistent expectation that just doing a 
dist-upgrade should be enough and we see day-in-day-out that people do *not* 
read the release notes.

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7


-- 
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/201410192110.11251.stu...@debian.org

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

[Josh Triplett]

On Sat, 18 Oct 2014 20:59:54 -0700 Russ Allbery  wrote:
> When one of you has a chance, could you update this bug with the current
> thinking around how to handle upgrades, around the ordering of
> dependencies in libpam-systemd, and some of the other ideas (such as
> attempting to detect systems with /etc/inittab configuration or init
> scripts that don't follow systemd's assumptions) raised in those threads?

Not speaking for the systemd maintainers, but I just wrote and tested
the following shell code to detect sysvinit-specific configuration
(modified /etc/inittab or modified init scripts) that may indicate a
need for manual sysadmin action (and thus a prompt).  This needs a bit
of work to add potential serial console getty lines generated by
finish-install to the list of "expected" lines, as well as any other
lines generated by older versions of finish-install.

inittab_unusual_lines="$(
grep '^[^#]' /etc/inittab |
while read line ; do
case "$line" in
'id:2:initdefault:') ;;
'si::sysinit:/etc/init.d/rcS') ;;
'~~:S:wait:/sbin/sulogin') ;;
'l0:0:wait:/etc/init.d/rc 0') ;;
'l1:1:wait:/etc/init.d/rc 1') ;;
'l2:2:wait:/etc/init.d/rc 2') ;;
'l3:3:wait:/etc/init.d/rc 3') ;;
'l4:4:wait:/etc/init.d/rc 4') ;;
'l5:5:wait:/etc/init.d/rc 5') ;;
'l6:6:wait:/etc/init.d/rc 6') ;;
'z6:6:respawn:/sbin/sulogin') ;;
'ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now') ;;
'pf::powerwait:/etc/init.d/powerfail start') ;;
'pn::powerfailnow:/etc/init.d/powerfail now') ;;
'po::powerokwait:/etc/init.d/powerfail stop') ;;
'1:2345:respawn:/sbin/getty 38400 tty1') ;;
'2:23:respawn:/sbin/getty 38400 tty2') ;;
'3:23:respawn:/sbin/getty 38400 tty3') ;;
'4:23:respawn:/sbin/getty 38400 tty4') ;;
'5:23:respawn:/sbin/getty 38400 tty5') ;;
'6:23:respawn:/sbin/getty 38400 tty6') ;;
*) echo "$line" ;;
esac
done
)"

modified_initscripts="$(
grep -lE '^/etc/init\.d/' /var/lib/dpkg/info/*.conffiles |
xargs basename -s '.conffiles' |
xargs dpkg -V |
grep '^..5.. c /etc/init\.d/' |
cut -d' ' -f3
)"

if [ -n "$inittab_unusual_lines" ] || [ -n "$modified_initscripts" ]; then
# Substitute these variables into a debconf template and display it
cat 

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

[Russ Allbery]

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.

When one of you has a chance, could you update this bug with the current
thinking around how to handle upgrades, around the ordering of
dependencies in libpam-systemd, and some of the other ideas (such as
attempting to detect systems with /etc/inittab configuration or init
scripts that don't follow systemd's assumptions) raised in those threads?

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.

Thanks!

-- 
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/87zjcsaev9@hope.eyrie.org