Bug#762194: Proposal for upgrades to jessie

[Svante Signell]

Hello,

Below is a proposal for a (partial) solution for the upgrade problem of
keeping the installed init system:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765803

This has been discussed privately among selected users/DM/DDs and since
the deadline for the ctte is December 4, it has to be known to them (and
-devel for comments).

(another partial? solution is to change order of the (pre-)depends of
the init package, as proposed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194
with preliminary results in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#142)

1) Heavily advertise (release-notes?) that doing an upgrade from
wheezy/etc to jessie will give you systemd as init system and inform
about the apt pinning solution.

2) In case you missed doing the above, you get a debconf prompt when
installing the init package that if you want to keep sysv/openrc/etc
continue with the installation, get systemd-sysv installed and after
that install sysvinit-core and do the pinning. (This is suboptimal, many
peoples systems could be broken at first reboot, we will find out in due
time).

Another issue is upgrading from testing/sid?/etc (different status) to
jessie:
3) Heavily advertise (again in release notes?) that you need to install
sysvinit-core and add the pinning file _before_ dist-upgrading.

Note that the only technical in the above is the creation of a debconf
prompt in pre/post-inst of the init package. All the rest is just a
matter of writing.

Sincerely!

[Thorsten Glaser]

Post by Svante Signell
(another partial? solution is to change order of the (pre-)depends of
the init package, as proposed in

No, that breaks due to the bug in debootstrap=E2=80=99s dependency =E2=80=
=9Cresolver=E2=80=9D
(see #557322, #668001, #768062) and the unwillingness of KiBi to fix
that. That is, it breaks fresh installs.

Post by Svante Signell
1) Heavily advertise (release-notes?) that doing an upgrade from
wheezy/etc to jessie will give you systemd as init system and inform
about the apt pinning solution.

That should be a given, a minimum, independent of the others.

Post by Svante Signell
2) In case you missed doing the above, you get a debconf prompt when

No, no, no, no, no, no, no!

Again: aborting the dist-upgrade in the debconf of one
package may leave the system an ugly mess, especially
if you don=E2=80=99t preconfigure packages.

The linux-image-* check in their prerm for an attempt
to remove the running kernel. Even that is borderline,
and only somewhat acceptable because you would not
normally do that during a dist-upgrade.

This is not =E2=80=9Csuboptimal=E2=80=9D, this invites not just new
bugs but new classes of bugs. Recovering the system
after that is going to be hell.

One thing you *could* do is a debconf warning (just
a message!) after the switch to systemd, to tell users
to switch back manually *before* rebooting (for these
cases where e.g. systemd is incompatible with the SoC=E2=80=99s
2.6 kernel you absolutely must run). Does that work,
anyway (i.e. does installing systemd and immediately
reverting to sysvinit leave the system net unchanged,
modulo the dependencies it pulls in (see planet post))?

Post by Svante Signell
3) Heavily advertise (again in release notes?) that you need to install
sysvinit-core and add the pinning file _before_ dist-upgrading.

As I said, this should be a given.

Post by Svante Signell
Note that the only technical in the above is the creation of a debconf
prompt in pre/post-inst of the init package. All the rest is just a
matter of writing.

Right, and I believe that a debconf *message* is
appropriate, but a *prompt* with a choice to abort
the upgrade is wrong.

bye,
//mirabilos
--=20
Just a user=E2=80=A6

[Svante Signell]

Post by Thorsten Glaser

Post by Svante Signell
2) In case you missed doing the above, you get a debconf prompt when

No, no, no, no, no, no, no!
Again: aborting the dist-upgrade in the debconf of one
package may leave the system an ugly mess, especially
if you don’t preconfigure packages.

I did _not_ propose aborting the dist-upgrade here. Sorry for not being
clear enough. The proposed debconf prompt is just for information: <hit
return to continue>

[Svante Signell]

Post by Thorsten Glaser
Does that work,
anyway (i.e. does installing systemd and immediately
reverting to sysvinit leave the system net unchanged,
modulo the dependencies it pulls in (see planet post))?

I've installed testing (basic install) on a new box and immediately
after first reboot installed sysvinit-core. That worked for me, but as
written before, it can create problems for people having different
preferences set.

[Svante Signell]

Hello,

In the (last) hope that the CTTE will bring this issue on the agenda
next meeting on December 4. Additional information below and a short
summary.

Post by Svante Signell
(another partial? solution is to change order of the (pre-)depends of
the init package, as proposed in

No, that breaks due to the bug in debootstrap’s dependency “resolver”
(see #557322, #668001, #768062) and the unwillingness of KiBi to fix
that. That is, it breaks fresh installs.

Note, this (long-time) refusal to make changes to that package has to be
weighted in when the CTTE is discussing this issue: There are very small
patches available before the freeze Wed, 5 Nov 2014 (Sun, 22 Nov 2009
and Fri, 17 Oct 2014) that has not been addressed by the maintainer:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557322#24
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#20
and reported working
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#50

And according to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194
with preliminary results in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#142
the order of pre-depends for int init package should change from
Pre-Depends: systemd-sysv | sysvinit-core | upstart
to
Pre-Depends: sysvinit-core | systemd-sysv | upstart

(I hope I made the correct links and conclusions)

Post by Svante Signell
1) Heavily advertise (release-notes?) that doing an upgrade from
wheezy/etc to jessie will give you systemd as init system and inform
about the apt pinning solution.

That should be a given, a minimum, independent of the others.

I'll file a bug against release notes about the release-notes!

In summary:
a) Upgrades should _not_ change init: whatever is installed should be
kept.
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

More detailed:
1) Fix debootstrap bugs
2) Add a (non-aborting) debconf message referring to release-notes on
how to install sysvinit-core when installing from scratch.
3) Add information in release-notes on how to:
- Upgrade from stable/testing/sid to jessie to avoid getting
systemd-sysv installed (this should not strictly be needed if the ctte
chooses to decide that upgrades will _not_ switch init)
- Install sysvinit-core after installation and reboot after getting
systemd-sysv as default.

3.1) I'll file a bug against release-notes as written above.

[Thorsten Glaser]

Post by Svante Signell
the order of pre-depends for int init package should change from
Pre-Depends: systemd-sysv | sysvinit-core | upstart
to
Pre-Depends: sysvinit-core | systemd-sysv | upstart

That would probably require changes in d-i to ensure that
systemd is, indeed, installed by default on fresh installs,
but otherwise has the most chance of keeping existing systems
running properly, so I think that this change is fair, yes.

Post by Svante Signell
a) Upgrades should _not_ change init: whatever is installed should be
kept.

Are there any upgrade paths where software existing in wheezy
requires systemd in jessie? If so, these are corner cases where
switching init may or may not be avoidable; if not, present a
debconf message here. But the vast majority probably should not
(need to; even GNOME can work with the shim) switch, yes.

Post by Svante Signell
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

I think this is not fair, though. CTTE decided that systemd be
the default init system for Linux in jessie =E2=80=9Cperiod=E2=80=9D. That =
means
no debconf message required here.

Do note that new installs of kFreeBSD and Hurd should not get
systemd, but what exactly is probably up to the porters for lack
of a CTTE decision in that.

Post by Svante Signell
1) Fix debootstrap bugs

Yesplease!

bye,
//mirabilos
--=20
=C2=ABMyISAM tables -will- get corrupted eventually. This is a fact of life=
=2E =C2=BB
=E2=80=9Cmysql is about as much database as ms access=E2=80=9D =E2=80=93 =
=E2=80=9CMSSQL at least descends
from a database=E2=80=9D =E2=80=9Cit's a rebranded SyBase=E2=80=9D =E2=80=
=9CMySQL however was born from a
flatfile and went downhill from there=E2=80=9D =E2=80=93 =E2=80=9Cat least =
jetDB doesn=E2=80=99t claim to
be a database=E2=80=9D=09=E2=80=A3=E2=80=A3=E2=80=A3 Please, http://deb.li/=
mysql and MariaDB, finally die!

[Marco d'Itri]

Post by Svante Signell
a) Upgrades should _not_ change init: whatever is installed should be
kept.

I disagree: upgrades should get the default init system unless the
system administrator chooses otherwise.

Post by Svante Signell
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

It would be totally unacceptable to waste the time of every Debian user
with pointless advertisement.
This can be documented in the release notes, if needed.

[Niels Thykier]

Post by Marco d'Itri
[...]

Post by Svante Signell
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

It would be totally unacceptable to waste the time of every Debian user
with pointless advertisement.
This can be documented in the release notes, if needed.

I suspect it would fit better in the "installation-guide". The
release-notes concerns itself mainly with upgrades and not with "fresh
installs".

~Niels

[Thorsten Glaser]

=20

Post by Svante Signell
a) Upgrades should _not_ change init: whatever is installed should be
kept.

I disagree: upgrades should get the default init system unless the=20
system administrator chooses otherwise.

I disagree with you, and so does CTTE, this time: they said
that existing installations should retain their init system
=E2=80=93 which goes along with =E2=80=9Cupgrades should not change the sy=
=E2=80=90
sytem state=E2=80=9D generall =E2=80=93 as much as possible.

Post by Svante Signell
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

It would be totally unacceptable to waste the time of every Debian user=

=20

with pointless advertisement.

I actually have to agree here.

bye,
//mirabilos
--=20
Yes, I hate users and I want them to suffer.
=09-- Marco d'Itri on gmane.linux.debian.devel.general

[Ansgar Burchardt]

Post by Thorsten Glaser

Post by Marco d'Itri
I disagree: upgrades should get the default init system unless the
system administrator chooses otherwise.

I disagree with you, and so does CTTE, this time: they said
that existing installations should retain their init system
– which goes along with “upgrades should not change the sy‐
sytem state” generall – as much as possible.

No, the ctte did not say that. We had a flamewar about that
interpretation before.

Ansgar

[Thorsten Glaser]

Post by Ansgar Burchardt
No, the ctte did not say that. We had a flamewar about that
interpretation before.

That was almost word by word from
https://lists.debian.org/debian-devel-announce/2014/11/msg00000.html

bye,
//mirabilos
--=20

Post by Ansgar Burchardt

Why don't you use JavaScript? I also don't like enabling JavaScript in

Because I use lynx as browser.

+1
=09-- Octavio Alvarez, me and =E2=A1=8D=E2=A0=81=E2=A0=97=E2=A0=8A=E2=A0=95=
(Mario Lang) on debian-devel

[Ansgar Burchardt]

Post by Thorsten Glaser

Post by Ansgar Burchardt
No, the ctte did not say that. We had a flamewar about that
interpretation before.

That was almost word by word from
https://lists.debian.org/debian-devel-announce/2014/11/msg00000.html

See [1] and [2] and possibly other places.

Ansgar

[1] https://lists.debian.org/debian-ctte/2014/11/msg00046.html
[2] https://lists.debian.org/debian-ctte/2014/11/msg00049.html

[Neil McGovern]

Post by Thorsten Glaser

Post by Ansgar Burchardt
No, the ctte did not say that. We had a flamewar about that
interpretation before.

That was almost word by word from
https://lists.debian.org/debian-devel-announce/2014/11/msg00000.html

Hi Thorsten,

I think you may be misreading the text there. They /did not/ say that
the init system should not be switched. I'll try a simplified version
of the resolution below.

0) This is advice, it's non-binding.
1) The previous resolution was silent on automatic switching.
2) We've been asked to decide about automatic switching and...
3) We don't want to decide this while there's a GR going on.
4) Please propose changes which would make new installations get
systemd, and upgrades retain existing init so that...
5) We can decide what to do after the GR is over.

Hope this clarifies.

Neil

[Stephan Seitz]

Post by Marco d'Itri

Post by Svante Signell
a) Upgrades should _not_ change init: whatever is installed should be
kept.

I disagree: upgrades should get the default init system unless the
system administrator chooses otherwise.

Of course not. syslog-ng was not replaced by rsyslog when Debian changed
the default syslog. The grub1 bootloader was not replaced when Debian
changed to grub2. If Debian changed from exim to postfix the existing MTA
would not be changed.

So keep your hands of the init system on upgrades.

Post by Marco d'Itri

Post by Svante Signell
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

It would be totally unacceptable to waste the time of every Debian user
with pointless advertisement.

This question could be part of the expert menu.

Shade and sweet water!

Stephan

[Darren Salt]

I demand that Stephan Seitz may or may not have written...

Post by Stephan Seitz

Post by Marco d'Itri

Post by Svante Signell
a) Upgrades should _not_ change init: whatever is installed should be
kept.

I disagree: upgrades should get the default init system unless the
system administrator chooses otherwise.

Of course not. syslog-ng was not replaced by rsyslog when Debian changed
the default syslog. The grub1 bootloader was not replaced when Debian
changed to grub2. If Debian changed from exim to postfix the existing MTA
would not be changed.
So keep your hands of the init system on upgrades.

Seconded.

FWIW, I'm using lilo. That's still available, maintained and working, and I
see no reason to change: grub offers more complexity and more options, but
lilo does exactly what I want/need of it.

Post by Stephan Seitz

Post by Marco d'Itri

Post by Svante Signell
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

It would be totally unacceptable to waste the time of every Debian user
with pointless advertisement.

This question could be part of the expert menu.

I for one would welcome this. When I last checked, there was such a question
regarding choice of boot loader (and, presumably, that's still there).
--
| _ | Darren Salt, using Debian GNU/Linux (and Android)
| ( ) |
| X | ASCII Ribbon campaign against HTML e-mail
| / \ | http://www.asciiribbon.org/

To light a candle is to cast a shadow.

[Tollef Fog Heen]

]] Svante Signell

[...]

Post by Svante Signell
And according to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194
with preliminary results in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#142
the order of pre-depends for int init package should change from
Pre-Depends: systemd-sysv | sysvinit-core | upstart
to
Pre-Depends: sysvinit-core | systemd-sysv | upstart
(I hope I made the correct links and conclusions)

That would require changes to a number of packages to ensure they end up
installing the default init. (vmdebootstrap, ganeti, fai at least comes
to mind). I think it would also be crazy for debootstrap to end up
installing a non-default init by default.

Arguably, debootstrap could be taught not to install an init at all, but
that tool will require adjusting all those other ways of installing
Debian as well as a good bunch of testing to ensure nothing breaks. I
don't think that would be appropriate at this stage of the freeze.

[Don Armstrong]

And according to https://bugs.debian.org/762194 with preliminary
results in https://bugs.debian.org/762194#142 the order of pre-depends
for int init package should change from
Pre-Depends: systemd-sysv | sysvinit-core | upstart
to
Pre-Depends: sysvinit-core | systemd-sysv | upstart

This message (#142) indicates that switching the dependency order will
change what debootstrap installs by default. This isn't acceptable, even
if we were to override the decision of the maintainers of the init
package to install systemd-sysv by default on upgrades.
--
Don Armstrong http://www.donarmstrong.com

Everyone has to die. And in a hundred years nobody's going to inquire
just how most people died. The best thing is to do it in the way that
strikes your fancy most.
-- Kenzaburō Ōe _Silent Cry_ p5

[Svante Signell]

One claim is changed, see below.

Post by Svante Signell
Hello,
a) Upgrades should _not_ change init: whatever is installed should be
kept.
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

Since there is no interest in adding a debconf message on new installs,
I wish for a menu entry in the advanced part of the installer to be able
to install a new system with sysvinit-core or upstart!

[Philipp Kern]

Post by Svante Signell
One claim is changed, see below.

Post by Svante Signell
Hello,
a) Upgrades should _not_ change init: whatever is installed should be
kept.
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

Since there is no interest in adding a debconf message on new installs,
I wish for a menu entry in the advanced part of the installer to be able
to install a new system with sysvinit-core or upstart!

That's even more unlikely than to add a debconf message (which would be
package-owned). Yes, debian-installer is frozen. This would add new
udebs, new strings, new everything. We're actually trying to release.

Kind regards
Philipp Kern

[Svante Signell]

Post by Philipp Kern

Post by Svante Signell
One claim is changed, see below.

Post by Svante Signell
Hello,
a) Upgrades should _not_ change init: whatever is installed should be
kept.
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

Since there is no interest in adding a debconf message on new installs,
I wish for a menu entry in the advanced part of the installer to be able
to install a new system with sysvinit-core or upstart!

That's even more unlikely than to add a debconf message (which would be
package-owned). Yes, debian-installer is frozen. This would add new
udebs, new strings, new everything. We're actually trying to release.

This is another nail in the Universal OS coffin: Let's move to devuan,
please! Use Debian as upstream (as long as it lives)

Yes, next Debian release is lendows, not jessie :(

[Miguel Figueiredo]

On 29-11-2014 19:40, Svante Signell wrote:
[...]

Post by Svante Signell
This is another nail in the Universal OS coffin: Let's move to devuan,
please! Use Debian as upstream (as long as it lives)
Yes, next Debian release is lendows, not jessie :(

Thanks! We appreciate less noise on these lists and on the next release
- which it's currently frozen, although you don't care.
Good luck.

[Adam D. Barratt]

Post by Svante Signell
This is another nail in the Universal OS coffin: Let's move to devuan,
please!

You are of course free to do that. This discussion is about what Debian
should do, however. If you wish to discuss Devuan, please do so in a
more appropriate forum.

Regards,

Adam

[Svante Signell]

Post by Adam D. Barratt

Post by Svante Signell
This is another nail in the Universal OS coffin: Let's move to devuan,
please!

You are of course free to do that. This discussion is about what Debian
should do, however. If you wish to discuss Devuan, please do so in a
more appropriate forum.

Yes, I'll do that. But it does not seem like you are realizing what is
happening unfortunately. Debian will not be as it was historically due
to this issue. Maybe the new DDs are to young to learn from history?

[Adam D. Barratt]

Post by Svante Signell
But it does not seem like you are realizing what is
happening unfortunately. Debian will not be as it was historically due
to this issue. Maybe the new DDs are to young to learn from history?

Please don't patronise people. Just because someone disagrees with you,
it doesn't mean that they're naive and unseeing and would be so much
better off if you could just lift the mist from in front of their eyes.

I'll stop contributing to the noise myself now, apologies to everyone
else.

Regards,

Adam

[Steve Langasek]

Post by Philipp Kern

Post by Svante Signell
One claim is changed, see below.

Post by Svante Signell
Hello,
a) Upgrades should _not_ change init: whatever is installed should be
kept.
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

Since there is no interest in adding a debconf message on new installs,
I wish for a menu entry in the advanced part of the installer to be able
to install a new system with sysvinit-core or upstart!

That's even more unlikely than to add a debconf message (which would be
package-owned). Yes, debian-installer is frozen. This would add new
udebs, new strings, new everything. We're actually trying to release.

Debian releases when it's ready. If large numbers of our users are going to
have a bad experience with jessie as a result of being switched to systemd,
then we should take appropriate steps to address that, even if that means
unfreezing the installer.

I am not saying that making init systems a choice in the installer is the
right solution here; I don't think that it is. But I also don't think that
the release freeze can reasonably be an argument against it.
--
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 Developer http://www.debian.org/
***@ubuntu.com ***@debian.org

[Philipp Kern]

Post by Steve Langasek
Debian releases when it's ready. If large numbers of our users are going to
have a bad experience with jessie as a result of being switched to systemd,
then we should take appropriate steps to address that, even if that means
unfreezing the installer.

Sure. But where is the evidence for that? Is there a bug that has been
agreed upon to be RC?

Post by Steve Langasek
I am not saying that making init systems a choice in the installer is the
right solution here; I don't think that it is. But I also don't think that
the release freeze can reasonably be an argument against it.

Not even the release freeze, rather the d-i freeze. Unless this is RC
for d-i, that is.

Kind regards
Philipp Kern

[Svante Signell]

Post by Philipp Kern

Post by Steve Langasek
Debian releases when it's ready. If large numbers of our users are going to
have a bad experience with jessie as a result of being switched to systemd,
then we should take appropriate steps to address that, even if that means
unfreezing the installer.

Sure. But where is the evidence for that? Is there a bug that has been
agreed upon to be RC?

Post by Steve Langasek
I am not saying that making init systems a choice in the installer is the
right solution here; I don't think that it is. But I also don't think that
the release freeze can reasonably be an argument against it.

Not even the release freeze, rather the d-i freeze. Unless this is RC
for d-i, that is

Ok, I've tried to no avail. Debian is no democracy (maybe never was).
ctte do as you feel there are no alternative solutions, just state the
fact with your decision EOT.

[Matthias Klumpp]

Post by Svante Signell

Post by Philipp Kern

Post by Steve Langasek
Debian releases when it's ready. If large numbers of our users are going to
have a bad experience with jessie as a result of being switched to systemd,
then we should take appropriate steps to address that, even if that means
unfreezing the installer.

Sure. But where is the evidence for that? Is there a bug that has been
agreed upon to be RC?

Post by Steve Langasek
I am not saying that making init systems a choice in the installer is the
right solution here; I don't think that it is. But I also don't think that
the release freeze can reasonably be an argument against it.

Not even the release freeze, rather the d-i freeze. Unless this is RC
for d-i, that is

Ok, I've tried to no avail. Debian is no democracy (maybe never was).

It never was a democracy - it was and is a meritocracy, described as
"the reign of knowledge"[1].
And we are going quite well with that.

[1]: http://debian-handbook.info/browse/wheezy/sect.debian-internals.html#idp5715200

[Philip Hands]

Hi Steve,

Post by Steve Langasek

Post by Philipp Kern

Post by Svante Signell
One claim is changed, see below.

Post by Svante Signell
Hello,
a) Upgrades should _not_ change init: whatever is installed should be
kept.
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

Since there is no interest in adding a debconf message on new installs,
I wish for a menu entry in the advanced part of the installer to be able
to install a new system with sysvinit-core or upstart!

That's even more unlikely than to add a debconf message (which would be
package-owned). Yes, debian-installer is frozen. This would add new
udebs, new strings, new everything. We're actually trying to release.

Debian releases when it's ready. If large numbers of our users are going to
have a bad experience with jessie as a result of being switched to systemd,
then we should take appropriate steps to address that, even if that means
unfreezing the installer.
I am not saying that making init systems a choice in the installer is the
right solution here; I don't think that it is. But I also don't think that
the release freeze can reasonably be an argument against it.

How can someone be "switched to systemd" on a fresh install?

If you were pointing out an instance where upgrades could bite users,
that would be different, and might well be an RC bug.

Apparently however, you're talking about the installer, which has
nothing to do with upgrades, so cannot result in anything being
"switched" (well, not unless you're saying that the person is being
switched from being one sort of user to another, and might find that a
bad experience ... but then I've no idea what the "appropriate steps"
might be ;-) )

Cheers, Phil.

P.S. For those that think there's no choice when installing:

https://wiki.debian.org/systemd#Installing_without_systemd

I'd suggest that anyone that knows enough to have an opinion about their
preferred init will be able to manage that simple extra step with ease.

[Matthias Urlichs]

Hi,

Post by Philip Hands
https://wiki.debian.org/systemd#Installing_without_systemd
I'd suggest that anyone that knows enough to have an opinion about their
preferred init will be able to manage that simple extra step with ease.

+1

One might apply the same argument to upgrading 

(assuming that the not-yet-implemented warnings,
re inittab/fstab/runlevels, do not trigger)

[Wolodja Wentland]

Post by Steve Langasek

Post by Philipp Kern
That's even more unlikely than to add a debconf message (which would be
package-owned). Yes, debian-installer is frozen. This would add new
udebs, new strings, new everything. We're actually trying to release.

Debian releases when it's ready. If large numbers of our users are going to
have a bad experience with jessie as a result of being switched to systemd,
then we should take appropriate steps to address that, even if that means
unfreezing the installer.

Indeed. Jessie should be released once "large numbers of our users [will] no
longer have a bad experience as a result of being switched to systemd [because
all relevant bugs have been fixed]".

As somebody who is active in user support on IRC I dread the jessie release if it
means that we will ask people for years to come if they have switched to systemd
after their upgrade and, if not, walk them through the process. So far most
users who had a bad experience with jessie did so because they did *not* switch
and the fact that -shim wasn't ready.

"having a bad experience" should directly translate into bugs that can, and have
to, be fixed before the release. I would welcome a more technical discussion at
this point rather than an emotional one.

Thank you and everybody else for their wonderful work and patience.

[Svante Signell]

Post by Svante Signell
Hello,
a) Upgrades should _not_ change init: whatever is installed should be
kept.
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.
1) Fix debootstrap bugs
2) Add a (non-aborting) debconf message referring to release-notes on
how to install sysvinit-core when installing from scratch.
- Upgrade from stable/testing/sid to jessie to avoid getting
systemd-sysv installed (this should not strictly be needed if the ctte
chooses to decide that upgrades will _not_ switch init)
- Install sysvinit-core after installation and reboot after getting
systemd-sysv as default.
3.1) I'll file a bug against release-notes as written above.

Hopefully the ctte will make a decision on init system for upgrades to
Jessie today!

FYI: Bugs for release-notes on upgrades, #771825, and installation-guide
(and perhaps debian wiki) on new installs (pending), are in the pipe!

[Neil McGovern]

Hi,

Post by Svante Signell
1) Heavily advertise (release-notes?) that doing an upgrade from
wheezy/etc to jessie will give you systemd as init system and inform
about the apt pinning solution.
3) Heavily advertise (again in release notes?) that you need to install
sysvinit-core and add the pinning file _before_ dist-upgrading.

See
https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/issues.dbk?view=markup
lines 170 to 223.

Are you after something different? How about raising a bug against the
release-notes package before asking tech-ctte to do something?

Post by Svante Signell
Note that the only technical in the above is the creation of a debconf
prompt in pre/post-inst of the init package. All the rest is just a
matter of writing.

Alternatively: The only hard bit of the above is the creation of the
release notes. All the rest is just a matter of coding.

Neil
--

[Svante Signell]

Post by Neil McGovern
Hi,

Post by Svante Signell
1) Heavily advertise (release-notes?) that doing an upgrade from
wheezy/etc to jessie will give you systemd as init system and inform
about the apt pinning solution.
3) Heavily advertise (again in release notes?) that you need to install
sysvinit-core and add the pinning file _before_ dist-upgrading.

See
https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/issues.dbk?view=markup
lines 170 to 223.
Are you after something different? How about raising a bug against the
release-notes package before asking tech-ctte to do something?

Is it possible to get access to edit those pages? By filing a bug
against release-notes?

Post by Neil McGovern

Post by Svante Signell
Note that the only technical in the above is the creation of a debconf
prompt in pre/post-inst of the init package. All the rest is just a
matter of writing.

To clarify: debconf "prompt" -> debconf "message", meaning that the
install is not to be aborted, only an informal message is written and
<hit CR to continue>. Is it possible to propose a text here?

Post by Neil McGovern
Alternatively: The only hard bit of the above is the creation of the
release notes. All the rest is just a matter of coding.

YMMV

[Neil McGovern]

Post by Svante Signell

Post by Neil McGovern
Hi,

Post by Svante Signell
1) Heavily advertise (release-notes?) that doing an upgrade from
wheezy/etc to jessie will give you systemd as init system and inform
about the apt pinning solution.
3) Heavily advertise (again in release notes?) that you need to install
sysvinit-core and add the pinning file _before_ dist-upgrading.

See
https://anonscm.debian.org/viewvc/ddp/manuals/trunk/release-notes/en/issues.dbk?view=markup
lines 170 to 223.
Are you after something different? How about raising a bug against the
release-notes package before asking tech-ctte to do something?

Is it possible to get access to edit those pages? By filing a bug
against release-notes?

https://www.debian.org/doc/cvs, though I suggest a patch would probably
be better, and that should be a bug against release-notes.

Post by Svante Signell

Post by Neil McGovern

Post by Svante Signell
Note that the only technical in the above is the creation of a debconf
prompt in pre/post-inst of the init package. All the rest is just a
matter of writing.

To clarify: debconf "prompt" -> debconf "message", meaning that the
install is not to be aborted, only an informal message is written and
<hit CR to continue>. Is it possible to propose a text here?

Post by Neil McGovern
Alternatively: The only hard bit of the above is the creation of the
release notes. All the rest is just a matter of coding.

Indeed, my point was that 'just writing text' doesn't mean it happens -
we've traditionally been very understaffed in that bit of the project.

Neil