Bug#771561: closed by Ben Hutchings <ben at decadent.org.uk> (Re: systemd package is missing dependency on Linux kernel (linux-image?))

[Nils Dagsson Moskopp]

Matthias Klumpp <mak at debian.org> writes:

> 2014-11-30 21:01 GMT+01:00 Nils Dagsson Moskopp <nils at dieweltistgarnichtso.net>:
>> What course of action would do propose to ensure that systemd is always
>> upgraded in lockstep with the kernel version? Maybe have a versioned
>> ”Breaks” entry for systemd regarding older Linux kernel versions?
>
> Unfortunately, you can't ensure that - people might still boot an
> older kernel, or compile their own kernel and run that instead of what
> we ship with Debian.

Of course you cannot ensure that people who run systemd will break their
systems by sidestepping package management. You could, however, accept
that the common case of someone upgrading the OS, should not break it.

I think this is not a question of if, but when systemd upstream will
increase the kernel version numbers they still do support. They have
shown that they stay close to their plans – except when it involves
maintaining backward compatibility “for a long time” (I mean udev).

> The best thing would IMHO be a check in systemd to abort boot with a
> meaningful message in case an unsupported (= too old) kernel is used.

It would certainly be helpful, but really, where would you go from that?
If you could just revert to the previous state of the system (e.g. init
other than systemd, older version of systemd), this would not present a
problem. After reading the meaningful message, how would a user proceed?

Would it be possible to test systemd inside a container or VM as part of
the package upgrade process? Would you be willing to depend on snapshot
features delivered by a file system (btrfs) to make upgrades reliable?

> Also, the systemd package can only be updated if the kernel providing
> features it needs is set as default (this still wound't solve the case
> of partial upgrades though).

I read it as this is already the case. Good! However, that still means
that the systemd package does not specify its dependencies correctly –
no one can independently reason about it, because the fact that it
depends on Linux kernel versions stays out of band information.

I have a suspicion that the package management breakage that occurs as
part of the deliberate breakage delivered by systemd upstream will be
sufficiently worked around in some systemd release, obsoleting dpkg.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 212 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20141130/9b42bc87/attachment-0002.sig>