On Sun, Nov 16, 2014 at 08:52:37PM +0200, Robert wrote:
This was recently posted on #systemd-devel:
To make this clear, we expect that systemd and kernels are updated in
lockstep. We explicitly do not support really old kernels with really
new systemd. So far we had the focus to support up to 2y old kernels
(which means 3.4 right now), but even that should be taken with a grain
of salt, as we already made clear that soon after kdbus is merged into
the kernel we'll probably make a hard requirement on it from the systemd
side.
This is a very onerous requirement in the embedded world. There are many
embedded platforms sold today that only have 2.6.X BSPs. While I agree
that the BSP from vendors should be better (and it is getting better
thanks to devicetree), it seems that we are doomed to run ancient
userspace to match our ancient kernels.
This change will probably hit me the hardest and for me it really cuts
into what linux means. It used to be that I could run the same userspace
on my tiny embedded device, my desktop or on the server --- the only
difference being the kernel.
It seems like the only solution here is to abandon debian and fall back
to OpenEmbedded or buildroot.
Not necessarily. If debian supports your embedded architecture, then
you'll get the right thing. Now there's a number of avenues that Debian
could take:
* Backport the necessary features in the newer kernel to the older
kernel (the bigger the change, though, the harder this will be as it
will only be Debian supporting it, rather than the upstream kernel
team)
* Disconnect the 'lockstep' connection. I don't know the details, but
it might be that, in practice, there is some wiggle room and the
kernel and userspace could be, say, the same minor version but
different patch levels.
* Special-case the architecture. At the moment, for example, systemd is
the default init with a Linux kernel; for the kfreebsd port cgroups
are unavailable so systemd doesn't work. So kfreebsd is special-cased
not to include systemd. If necessary, similar could be done for your
architecture.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5468f275.5020...@gmail.com
signature.asc
Description: Digital signature