custom-kernel downgrade and linux-libc-dev

[Henning Schild <henning.schild@siemens.com>]

Hi,

our custom kernel builds always generate a linux-libc-dev package
matching the kernel kernel version. So for a cip you would get
linux-libc-dev-4.4.xx.

Prebuild debian packages from upstream depend on a linux-libc-dev >=
<debian-expected-version>. I.e. you want build-essential in stretch,
you will end up with a "Depends: linux-libc-dev (>= 4.9.65-3)"
somewhere in your deps chain.
But if you are building a custom kernel lower than the expected version
you will end up with a smaller linux-libc-dev in the isar repo. And the
strong pinning will leave apt no choice but to give up and trying to
resolve the problem. So if you want to include i.e build-essential into
an image with a kernel downgrade, you will not be able to build that
image.

That issue is especially problematic since it will creap into the
buildchroot after the package was deployed by the first kernel build.
And you will end up with a setup where partial rebuilds involving
buildchroot changes will not work anymore.

In the layer i discovered this problem in i now remove the
linux-libc-dev package in a do_deploy_deb_prepend. That seems to be a
working hack for the downgrade case, but might not be the best idea for
an upgrade case.

But my current suggestion would be to ignore the whole issue of kernel
header compatibilty and never deploy the linux-libc-dev package from
custom kernel builds. Thoughts?

Henning