custom-kernel downgrade and linux-libc-dev

custom-kernel downgrade and linux-libc-dev

[Henning Schild]

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

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

[Jan Kiszka]

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

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

[Henning Schild]

Am Wed, 16 Jan 2019 20:16:14 +0100
schrieb 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.

True, i thought that would be hard to detect. But i think i found some
shell code to easily make that comparison using debian tools.

Henning

> Jan
>