Bug#727708: systemd jessie -> jessie+1 upgrade problems
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. 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.
> 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.
As an additional note:
> 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?
Repeating the same question multiple times in the same mail message is
extremely irritating. In the future, when discussing things on the
technical committee mailing list, please refrain from doing this. You can
assume that everyone reading your message understands which questions you
think are important and doesn't require this sort of artificial emphasis.
It comes across as badgering.
>> 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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: