Your message dated Thu, 01 May 2014 18:55:14 +0200
with message-id <53627c72.9020...@debian.org>
and subject line Re: Bug#746577: systemd-sysv: for upgrade safety, systemd-sysv
and sysvinit-core must be coinstallable
has caused the Debian Bug report #746577,
regarding systemd-sysv: for upgrade safety, systemd-sysv and sysvinit-core must
be coinstallable
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
746577: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746577
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: systemd-sysv
Version: 204-10
Severity: critical
Justification: breaks the whole system
Control: retitle -2 sysvinit-core: for upgrade safety, systemd-sysv and
sysvinit-core must be coinstallable
For safety of upgrades from wheezy to jessie, the process of upgrading
packages and installing new ones *must not* change either the currently-
running init or the init that will manage the system on the next boot.
A transition away from sysvinit must only occur as a result of a
deliberate sysadmin action with that specific effect, not as a side
effect of any other operation.
To achieve this, systemd-sysv and sysvinit-core must be coinstallable,
with an alternatives-like mechanism for deciding which package actually
provides init (if this can be done with actual alternatives for
/sbin/init, that would be ideal, but I suspect it cannot be that simple).
Other potential providers of /sbin/init should ideally also be included
in this mechanism, but because the default-for-new-installations is changing
in jessie from sysvinit to systemd, the cooperation of those two providers
is more important than the others.
severity:critical because, depending on how an installation is configured,
an unanticipated conversion to systemd absolutely can cause the system
to be unbootable, or fail to carry out its intended function (e.g. because
a network server no longer starts on boot as intended).
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (501, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
Am 01.05.2014 18:38, schrieb Andrei POPESCU:
>> To achieve this, systemd-sysv and sysvinit-core must be coinstallable,
>> with an alternatives-like mechanism for deciding which package actually
>> provides init (if this can be done with actual alternatives for
>> /sbin/init, that would be ideal, but I suspect it cannot be that simple).
>> Other potential providers of /sbin/init should ideally also be included
>> in this mechanism, but because the default-for-new-installations is changing
>> in jessie from sysvinit to systemd, the cooperation of those two providers
>> is more important than the others.
sysvinit-core and systemd-sysv are conflicting packages by design. They
are not meant to be co-installable.
>> severity:critical because, depending on how an installation is configured,
>> an unanticipated conversion to systemd absolutely can cause the system
>> to be unbootable, or fail to carry out its intended function (e.g. because
>> a network server no longer starts on boot as intended).
You didn't show any actual breakage, so closing the bug report. If you
can show us of actual breakage caused by the switch to systemd where the
system will not boot, we will certainly deal with it.
That saif, you can make the deliberate choice to use systemd-shim if you
prefer.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
