From: Henning Schild <henning.schild@siemens.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: isar-users <isar-users@googlegroups.com>
Subject: Re: custom-kernel downgrade and linux-libc-dev
Date: Thu, 17 Jan 2019 11:06:24 +0100 [thread overview]
Message-ID: <20190117110624.40c457c4@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <a300cb3f-fff5-348c-af09-7911581964ee@siemens.com>
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
>
prev parent reply other threads:[~2019-01-17 10:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-16 16:27 Henning Schild
2019-01-16 19:16 ` Jan Kiszka
2019-01-17 10:06 ` Henning Schild [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190117110624.40c457c4@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox