Re: Bug#762194: Automatic switch to systemd on wheezy->jessie upgrades (thoughts)
Am 2014-12-04 18:21, schrieb Adam Borowski:
On Thu, Dec 04, 2014 at 05:25:26PM +0100, Christian Seiler wrote:
- Switchig depends order of init [1]
(sysvinit-core before systemd-sysv)
-> won't work, because init is Essential, but systemd-sysv
isn't,
so this change would default the init system to sysvinit for
jessie (which is against the TC ruling from earlier this
year,
so unless you'd want to overrule that... ;-))
That's why in my proposal the installation of systemd-sysv by default
is
moved to debootstrap.
Unfortunately, that has its own set of problems. People want to be
able to bootstrap jessie from other distributions, and from previous
Debian versions (which is why an update to debootstrap was accepted
into s-p-u recently to fix a bug so that jessie could be bootstrapped
from jessie, see [1]).
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768444
Note that there is also cdebootstrap, which you'd also have to
modify, and I honestly don't know what some other tools that can
install Debian use internally do.
Also, it is intuitive to keep changes to the default install in
debootstrap
rather than in dependencies. And it makes future changes of the
default
easy without breaking existing systems.
With the init metapackage, if it stays the way it is, then this is
not the case - because a change in the init metapackage order will
not affect existing systems anymore, it will just affect new systems.
So instead of hardcoding behavior in debootstrap, dependencies are
precisely the right way to go, in my eyes.
As for reasons not to switch, you did not mention the multitude of
"breaks
the whole system" (ie, severity:critical) bugs in common
configurations.
These include:
* vservers/containers
If you look at what most container solutions do in order to 'support'
current systems, they override quite a lot of the init script logic
in order not to do stuff they shouldn't do. With the current state of
things, I never had the expectation that dist-upgrading a container
would even remotely work, and I've never tried that.
Note that containers have been painful for upgrades anyway, since
Etch/Lenny had VServer and something else, Squeeze still had VServer
but only if using the official kernel, if your hardware required you
to use a backports kernel, then you couldn't use VServer anymore. In
with Squeeze came LXC as a possible alternative, but when it came to
Wheezy, subtle stuff changed again (e.g. /run directory, especially
if you wanted to run the container without CAP_SYS_ADMIN).
Also: jessie will be the first version of Debian that will have a
kernel that supports unpriviledged (user namespace) containers. That
alone is something worth reinvestigating the current setup for.
So my expectation for containers has always been: build it again on
the new operating system version, and then migrate the data over.
In fact, systemd actually gives me hope that this might not be the
case anymore in the not-too-distant future. For jessie it probably
won't work that way yet, but for stretch onwards (read: strech ->
buster upgrades) I really am hopeful that it will finally be possible
to just upgrade your container and everything will just work[tm].
Which has never been my experience so far.
* chroots that run daemons
What do you mean? systemd supports daemons with chroot just fine,
either directly (RootDirectory=) or even using traditional init
scripts.
* some configurations of encrypted lvm
Could you point me to a bug report on this? I'd like to help out with
that. I have systemd running on my home computer with an encrypted
LVM, and it does work, so what you are referencing is probably a
nasty bug that could be fixed.
* custom kernels (including those you can't upgrade)
That is indeed a problem.
* nonexistant filesystems in fstab (this one is being worked on)
I did mention that in my email.
Thus, the potential for breakage is simply too big. This is similar,
but
bigger in scope than the grub1->grub2 switch some years ago.
Well, in the end, it comes down to priorities, as to how much breakage
Christian
Reply to: