Re: Antw: [EXT] Re: version bump of minimal kernel version supported by systemd?

[Marc Pervaz Boocha <mboocha@xxxxxxxxxxx>]

On Thu, 2022-03-24 at 09:50 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Mar 24, 2022 at 08:21:37AM +0100, Ulrich Windl wrote:
> > I wonder:
> > 
> > Why not providing some test suite instead: If the test suite
> > succeeds, systemd
> > might work; if it doesn't, manual steps are needed.
> > My guess is that most people will quit trying once manual steps are
> > needed.
> > In addition the configure procedure could include a "support
> > window" (oldest
> > kernel supported, latest kernel supported).
> > And f the kernel is outside, print a warning at least that the
> > configuration
> > is not supported.
> > Still I guess the kernel version is not the only dependency...
> 
> We *are* providing a support window: the lower boundary is being
> discussed here, and the upper boundary is "open", always the latest
> kernel.
> 
> Support for old kernels consists of various workarounds for missing
> syscalls or other functionality, and local copies of kernel headers.
> Instead of trying to write tests for this, we just add the
> workarounds
> and then try not to touch them until they are removed.

Could there be a compromise? Another option is that have the core stuff
granteed use an old kernel like 4.4 but have all the "extras" like
networkd or some unit file derivatives depend on a much higher version.
Another option is to produce a warning and then bump the supported
version afer 1 or 2 years. The idea is that the users are not broken by
an upgrade but are "encouraged" to upgrade their kernel or move to some
lts distro release.

> 
> (And this is similar for other dependencies. There's a list with
> versions in README.)
> 
> Zbyszek

Thanks & Regards,
Marc Pervaz Boocha