Bug#727708: systemd jessie -> jessie+1 upgrade problems
On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote:
> Adrian Bunk <bunk@stusta.de> writes:
>
> > 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?
>
> I'd really like to keep this bug and this discussion focused on what's
> relevant to Debian as a project, so let's put this in that perspective.
> The oldest kernel that Debian supports is 2.6.32, released in 2009. But
> the oldest kernel that we support for upgrades, which is the only point at
> which systemd backward compatibility matters for Debian's support model,
> is 3.2.0, released in 2012.
Nitpick:
3.2.0 was released on January 5th 2012, so nearly 2011
> The window of backward compatibility that we
> need is roughly a release cycle plus six months (due to the releases that
> miss the release window). That's much less than the seven years of the
> eglibc example.
>
> We explicitly don't need to worry about whether systemd in unstable works
> with the oldstable kernel since we don't support that degree of
> cross-release compatibility.
>
> If we're going to ask systemd upstream questions about this, we should use
> the actual time period that we care about (about two and a half to three
> years), not four years and certainly not seven years.
I never talked about a seven years requirement, I was just listing the
glibc status quo when Josselin said "A notable similar example is eglibc".
I agree with you that around 3 years is a reasonable estimate for what
would be required from systemd.
> > 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.
>
> That's only true to the extent that we can hold all other packages back,
> so it's true exactly to the degree that we can choose when and how to
> adopt kdbus if we standardized on systemd. If we're holding back upstream
> packages, we can hold back systemd as well. This situation doesn't
> change, which is Josselin's point.
The "holding back upstream packages" would only be true for Linux-only
software that additionally chooses to drop the non-kdbus codepaths.
As I already explained, software like glib2.0 and libdbus that supports
non-Linux kernels will anyway have to continue to support non-kdbus
systems forever.
Is there actually any implementation other than glib2.0 and libdbus that
would be affected by a switch to kdbus?
>...
> >> 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.
>
> I see no evidence to support this contention apart from a bunch of
> speculation on your part about what *might* happen four years in the
> future if particular features missed a release window.
As an example, in the email from Josselin I was answering to he linked
to an email from Lennart [1] that states:
<-- snip -->
At the same time we will no longer support dbus-daemon for the system.
This will add a hard dependency of systemd on a very new kernel version.
However, to make this palatable we will try hard to keep kdbus.ko
compilable out-of-tree and easily backportable.
<-- snip -->
That is an explicit statement by upstream regarding what will happen in
the near future.
That makes it e.g. pretty clear that options 1. and 4. Josselin listed
for a jessie -> jessie+1 upgrade would definitely not be feasible if
kdbus won't be in the jessie kernel.
Yes, it is speculation that other new features (or even bugfixes)
might appear in the kernel and might become mandatory in systemd
between jessie and jessie+1.
But that is a risk, and it is a risk that is unique to the systemd
option since none of the alternatives is Linux-only. [2]
My whole point is not about kdbus specifically (which might even end up
in the jessie kernel), but about that (IMHO substantial) risk.
Whether or not this risk exists at all should be settled by asking
systemd upstream. If the answer is that for the required ~3 years
period compatibility with older kernels is guaranteed, then please
disregard my emails.
> Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
cu
Adrian
[1] http://lists.freedesktop.org/archives/systemd-devel/2013-March/009797.html
[2] any alternative that is not Linux-only cannot hard depend on
Linux-only kernel features
--
"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: