Re: custom-kernel downgrade and linux-libc-dev

[Jan Kiszka <jan.kiszka@siemens.com>]

On 16.01.19 17:27, Henning Schild wrote:
> 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?

Better solution is to only deploy linux-libc-dev if it is newer than the distro 
version. If you do not do that, you would break applications that explicitly 
want to exploit interfaces of newer kernels.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux