Bug#727708: systemd jessie -> jessie+1 upgrade problems
Hi Adrian,
Le lundi 16 décembre 2013 à 17:52 +0200, Adrian Bunk a écrit :
> Can you give a pointer to what guarantees systemd upstream makes
> regarding supporting older kernels?
Systemd is a userspace program. As such, it can has the same problems as
any other userspace programs. A notable similar example is eglibc: some
features require a newer kernel, and fallback code is needed when the
kernel is not recent enough.
So it really boils down to the time that passes between the integration
of a feature to the kernel and its use in systemd. For example, systemd
has a hard dependency on cgroups, but this feature has been in the
kernel from some time.
Problematic examples will not be frequent, and you are right to quote
kdbus as one of them.
> Assume kdbus gets merged into the upstream kernel after the kernel that
> ships with jessie.
>
> Would it be guaranteed that the systemd in jessie+1 will still be able
> to work with the jessie kernel, or is there even the slightest risk that
> systemd upstream might at some point make kdbus a mandatory requirement?
Upstream systemd will probably make kdbus a requirement:
http://lists.freedesktop.org/archives/systemd-devel/2013-March/009797.html
At this point, if the kernel in jessie does not support kdbus already,
we have several alternatives I can think of:
1. Maintain a code path to detect whether kdbus is available and
fall back to dbus-daemon in this case (better if we can convince
upstream to integrate the change)
2. Make a kdbus DKMS package and make it a dependency for systemd
3. Include kdbus in the jessie kernel in a point release
4. As a last resort, entirely disable kdbus in jessie+1
Note that if kdbus is adopted, we will need it regardless in glib2.0 and
libdbus. If we do not adopt systemd, we will have to make similar plans
of our own to provide a kdbus-enabled system bus and use it if the
kernel is recent enough. So this problem will exist, with the same
categories of solutions, even if we don’t switch to systemd.
> And with systemd absorbing functionality like module loading I could
> even imagine nightmare scenarios where additionally the jessie+1 kernel
> would only work with a jessie+1 systemd.
This would definitely be considered a bug in the kernel.
> Please clarify whether there is just a pointer to a statement from
> systemd upstream missing, or whether the statement "Compatibility at
> upgrade time should not be a concern either" is incorrect.
Maybe this was wrongly phrased: of course we should be concerned by
compatibility at upgrade time. But using systemd doesn’t cause more
compatibility problems than those we already have (e.g. with udev).
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Reply to: