[systemd-devel] providing backwards compatibility

[Kay Sievers]

On Fri, Jan 17, 2014 at 2:20 PM, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> On 17/01/14 09:42, Kay Sievers wrote:
>> This year will bring huge flag day compat breaks. We will drop all old
>> D-Bus support, we will require on a bleeding edge kernel, and so on.
>
> Flag-day compatibility breaks are a massive pain for distributions. The
> more things need to be upgraded in lockstep, the harder it is -
> particularly the kernel, since most distributions allow more than one
> kernel to be installed at a time, and switching the running kernel needs
> a reboot. Package dependency systems that were mainly designed for
> libraries and restartable daemons can easily guarantee "linux >= 3.67 is
> somewhere in the filesystem", but not "linux >= 3.67 was booted".

In the kdbus case it's easy, there will be zero backward compat here.
Only higher-level users of D-Bus should continue to run without
noticing it. Systemd, tools in the base OS, and dbus-daemon will not.

> I can see that a flag day is sometimes unavoidable, but please do
> consider it to be a significant cost. In particular, if your goal is for
> systemd to be a universal part of a "standard" Linux stack, avoiding
> flag-day upgrades whenever possible seems wise. I for one would like to
> be able to assume systemd's technical advantages when writing other
> software, but distributors who are uneasy about adopting systemd are not
> going to be reassured by plans that will break their upgrades.

We don't break things for fun, but the dependency on kdbus will be
hard switch, and there will be no way back. It's unfortunate that this
need to happen, but it's worth the pain.

There are no alternatives really, as soon as we start using kdbus
features, port the journal to kdbus (logging cannot use dbus-daemon
because of cyclic deps) the possibility for dbus-daemon to run is
over, and with that there will be hard requirement on a recent kernel.

> The kernel's policy is "don't break userspace" - isn't the init(1)
> equivalent "don't break the rest of userspace"?

No it isn't. We need to break things where progress in the base OS is
more worth than compatibility.

And working for years with enterprise systems, I call the kernel
maintainer's claim of not breaking userspace nothing but a dream. It's
a good goal, sure, but people just lie to themselves here with
statements like "forever" and such. The kernel/driver break interfaces
all the time. All that is reasonable stable is syscalls and old and
rather static interfaces like /proc.

People doing maintenance as their day job for many years just fix the
stuff and don't even tell anybody anymore. Mixing QA and development
makes not much sense, and it just doesn't work in reality how people
like to believe.

Kay