Bug#762194: Automatic switch to systemd on wheezy-jessie upgrades (thoughts)
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.
In scripts/{unstable,jessie}, function work_out_debs(), you add
systemd-sysv to the variable required. This can be done
unconditionally, or, preferably, only in the - variant, as other variants
either don't use init at all or are unbootable with systemd. And in some
use cases like pbuilder or non-lvm/btrfs sbuild size gains are important:
it takes longer to unpack the tarball than to build an average package.
I did test the following change:
=
work_out_debs () {
required=$(get_debs Priority: required)
== to ===
work_out_debs () {
required=$(get_debs Priority: required) systemd-sysv
=
and it does what you want.
On the other hand, relying on an upload to wheezy is quite fragile.
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.
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
* chroots that run daemons
* some configurations of encrypted lvm
* custom kernels (including those you can't upgrade)
* nonexistant filesystems in fstab (this one is being worked on)
* etc, etc.
Thus, the potential for breakage is simply too big. This is similar, but
bigger in scope than the grub1-grub2 switch some years ago.
--
// If you believe in so-called intellectual property, please immediately
// cease using counterfeit alphabets. Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.
--
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/20141204172145.ga12...@angband.pl
Bug#762194: Automatic switch to systemd on wheezy-jessie upgrades (thoughts)
Thanks. I found this post of your to be really thought-provoking and useful and an example of the sort of discourse we should strive to when discussing these issues. I think the discussion of switching default inits in the future is something to particularly consider. --Sam -- 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/tslfvcv8h4f@mit.edu
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 -- 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/57d7f2a72b8bbe7cb5edd00c0fe0e...@iwakd.de
Bug#762194: Automatic switch to systemd on wheezy-jessie upgrades (thoughts)
Sorry, stupid webmail, sent my email to early... and only to the mailing list, not the bugtracker... :( To make sure it's recorded in the bug, and I also added something to the end: Am 2014-12-04 19:31, schrieb Christian Seiler: 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 people consider acceptable, in contrast to the other upsides and downsides of the change. I don't think it is unreasonable that some people come down on the other side of this issue. As I said in my first email, I don't think there is an easy answer here. Christian -- 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/7a227d36ce9b9b23dcb52cc433538...@iwakd.de
Bug#762194: Automatic switch to systemd on wheezy-jessie upgrades (thoughts)
]] Christian Seiler Am 2014-12-04 18:21, schrieb Adam Borowski: * 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. I believe Adam refers to the fact that the cryptsetup support in systemd doesn't support keyscript= in crypttab. -- 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/87r3wf2na2@xoog.err.no
