Bug#727708: systemd jessie -> jessie+1 upgrade problems
On Tue, Dec 17, 2013 at 12:38:50PM +0100, Josselin Mouette wrote:
> Hi Adrian,
Hi Josselin,
> 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.
this hits exactly the core of the problem:
The minimum supported Linux kernel version in glibc is currently 2.6.16,
released in 2006. And I'd trust glibc upstreamt that this requirement
won't suddenly be bumped to a quite recent version.
Is there any explicit commitment from systemd upstream that releases of
systemd releases around 2017 will still contain fallback code to work
on kernels from 2013/2014?
> 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?
First of all, I want to emphasize that kdbus is just an example.
kdbus might even be in the jessie kernel so that this specific problem
might not show up.
But other systemd/kernel dependencies might get added at any point.
> 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
Is there any explicit commitment from systemd upstream that systemd
would not get a hard dependency on anything only available in kdbus?
> (better if we can convince
> upstream to integrate the change)
Feel free to prove me wrong, but the very core of this problem is that
I'd expect Lennart to give to a question
Will 2017 systemd releases support 2013 kernels?
the answer
Of course not!
> 2. Make a kdbus DKMS package and make it a dependency for systemd
> 3. Include kdbus in the jessie kernel in a point release
This might be possible in the kdbus example where the kernel code is a
standalone module (but 2. or 3. would cause much pain e.g. for correctly
handling custom kernels).
If systemd depends on new kernel features/changes that touch kernel
internals, these would not be options.
> 4. As a last resort, entirely disable kdbus in jessie+1
Is there any explicit commitment from systemd upstream that systemd
in 2016/2017 will not have a hard dependency on features not in kernels
available today?
jessie+1 will be released around 2017/2018, and I would not be surprised
if systemd will start on 2014 to depend on kdbus with no other option
possible.
What would you do in such a situation?
Ship a 2014 systemd in jessie+1?
Even if GNOME decides to depend on features from more recent systemd
releases?
> Note that if kdbus is adopted, we will need it regardless in glib2.0 and
> libdbus.
But without systemd Debian is free to make the decision when and how to
adopt kdbus. If you add a systemd version that required kdbus into the
mix, the upgrade becomes messy.
glib2.0 and libdbus are not Linux-only, so their upstream will have to
provide and support the current non-kdbus codepaths.
That would make it an easily feasible option to solve any
jessie -> jessie+1 upgrade issues by not enabling kdbus in
glib2.0 and libdbus for jessie+1 at all, or by enabling both
kdbus and non-kdbus codepaths and choose one at runtime.
> 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.
Software like glib2.0 and libdbus that supports non-Linux kernels will
anyway have to continue to support non-kdbus systems.
Is there any explicit commitment from systemd upstream that systemd
in 2016/2017 will not have a hard dependency on features not in kernels
available today?
> > 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.
I don't think problems are likely in this direction, but I wouldn't rule
that out completely.
> > 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).
The exact opposite it true.
udev used to be the one package causing huge upgrade headaches back in
it's early days when the ABI between udev and the kernel was changing.
Later (at least until it was moved into systemd) it was mature and did
not cause such problems.
systemd is the former udev problems on steroids.
The potential upgrade problems I am talking about come from the fact
that systemd is relatively new software under heavy developement.
In a few years when systemd will be mature and and not require
new kernel ABIs these upgrade such problems will likely disappear
just as they did with udev.
> Cheers,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: