]] Zack Weinberg
On 05/06/2014 08:08 AM, Tollef Fog Heen wrote:
]] Zack Weinberg
On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen tfh...@err.no wrote:
]] Zack Weinberg
Fundamentally what I want is a bulletproof procedure for reverting to
sysvinit in case something goes wrong.
On Fri, May 9, 2014 at 4:48 AM, Tollef Fog Heen tfh...@err.no wrote:
]] Zack Weinberg
Ah, I understand now. Yes, this + systemd-sysv and upstart *also* stop
shipping /sbin/init (it becomes a symlink under control of the
administrator) + documentation would be a satisfactory conclusion as far
On 05/06/2014 01:37 AM, Martin Pitt wrote:
Zack Weinberg [2014-05-05 20:29 -0400]:
I contend that, therefore, systemd-sysv, sysvinit-core, *and*
systemd-shim (and upstart as well) (quotation marks indicate package
names) should *all* be coinstallable; an upgrade from wheezy should
install
On 05/06/2014 02:39 AM, Michael Stapelberg wrote:
Hi Zack,
Zack Weinberg za...@panix.com writes:
Note that coinstallability is not enough -- the bulletproof procedure
(e.g. update-init-system) must also be implemented, shipped, and
documented.
Your tone is way out of line. Who are you to
On 05/06/2014 08:08 AM, Tollef Fog Heen wrote:
]] Zack Weinberg
On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen tfh...@err.no wrote:
]] Zack Weinberg
Fundamentally what I want is a bulletproof procedure for reverting to
sysvinit in case something goes wrong.
Sounds like you're arguing
Hi Zack,
Zack Weinberg za...@panix.com writes:
Note that coinstallability is not enough -- the bulletproof procedure
(e.g. update-init-system) must also be implemented, shipped, and
documented.
Your tone is way out of line. Who are you to tell us what we _must_ do?
That’s not how it works.
]] Zack Weinberg
On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen tfh...@err.no wrote:
]] Zack Weinberg
Fundamentally what I want is a bulletproof procedure for reverting to
sysvinit in case something goes wrong.
Sounds like you're arguing that sysvinit-core should no longer ship
On 2014-05-03 12:18 PM, Tollef Fog Heen wrote:
Zack Weinberg wrote:
1) Switching from sysvinit to systemd (and vice versa, if necessary)
should be accomplished via a command dedicated to the purpose; it
should *not* occur as a side effect of installing, removing,
upgrading, or downgrading any
Hi Zack,
Fundamentally we agree with you of course. The devil is in the detail,
though: sysvinit-core and systemd are coinstallable, for all the reasons
you explained.
However, you seem to be using a package which depends on libpam-systemd,
which, translated to English, means the package is
]] Zack Weinberg
On 2014-05-03 12:18 PM, Tollef Fog Heen wrote:
Zack Weinberg wrote:
1) Switching from sysvinit to systemd (and vice versa, if necessary)
should be accomplished via a command dedicated to the purpose; it
should *not* occur as a side effect of installing, removing,
On Mon, May 5, 2014 at 5:40 PM, Tollef Fog Heen tfh...@err.no wrote:
]] Zack Weinberg
Fundamentally what I want is a bulletproof procedure for reverting to
sysvinit in case something goes wrong.
Sounds like you're arguing that sysvinit-core should no longer ship
/sbin/init, then, so
On 05/05/2014 03:43 PM, Michael Stapelberg wrote:
Hi Zack,
Fundamentally we agree with you of course. The devil is in the detail,
though: sysvinit-core and systemd are coinstallable, for all the reasons
you explained.
However, you seem to be using a package which depends on
Zack Weinberg [2014-05-05 20:29 -0400]:
I contend that, therefore, systemd-sysv, sysvinit-core, *and*
systemd-shim (and upstart as well) (quotation marks indicate package
names) should *all* be coinstallable; an upgrade from wheezy should
install *both* systemd-sysv and systemd-shim if not
]] Zack Weinberg
On Fri, May 2, 2014 at 12:48 PM, Michael Biebl bi...@debian.org wrote:
This is already possible today: The systemd package (intentionally)
doesn't conflict with sysvinit-core since there are no file conflicts.
You can install it and boot with init=/lib/systemd/systemd.
Control: reopen -1
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.
I believe you have missed the point of the bug report. This is not
about
I don't wish to play bug tracker ping-pong here, but I feel that you
are still missing the point. This is not about the default for new
installations, this is not about opt-out versus opt-in to the switch.
This is about *upgrade safety*.
Upgrade safety, IMNSHO, requires a stabilization point in
Am 02.05.2014 18:27, schrieb Zack Weinberg:
I don't wish to play bug tracker ping-pong here, but I feel that you
are still missing the point. This is not about the default for new
installations, this is not about opt-out versus opt-in to the switch.
This is about *upgrade safety*.
On Fri, May 2, 2014 at 12:48 PM, Michael Biebl bi...@debian.org wrote:
This is already possible today: The systemd package (intentionally)
doesn't conflict with sysvinit-core since there are no file conflicts.
You can install it and boot with init=/lib/systemd/systemd.
The systemd-sysv
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
Control: reassign -1 src:systemd 204-10
On Jo, 01 mai 14, 11:22:57, Zack Weinberg wrote:
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
20 matches
Mail list logo
