Re: [PATCH 0/3] linux-custom: Split up binaries from kernel headers to kbuild packages

["Koch, Stefan" <stefan-koch@siemens.com>]

On Tue, 2022-11-15 at 18:23 +0100, Jan Kiszka wrote:
> On 15.11.22 14:44, Uladzimir Bely wrote:
> > In mail from среда, 9 ноября 2022 г. 13:32:45 +03 user Koch, Stefan
> > wrote:
> > > Hi
> > > 
> > > This patchset is a set of three patches:
> > > - Support overwriting configured schroot dir
> > > - Split up binaries from kernel headers to kbuild packages
> > > - Update custom_kernel docs for split up of kernel scripts and
> > > tools
> > > 
> > 
> > Just some thoughts regarding schroot path overwriting...
> > 
> > What if `linux-custom` recipe could disable specific components?
> 
> Right, I sill wanted to follow up on that: Debian build profiles can
> do
> the trick here. Define one for "host tools only", and only build that
> in
> the second step.

- I have sucessfully set up a prototype of second patchset that uses
the debian build profiles approach.

> 
> > 
> > I mean, currently we have this feature only for `linux-libc-dev`
> > package, that 
> > is disabled when "nolibcdev" build profile is selected. If we added
> > similar 
> > build profiles for other components, we could disable also `linux-$
> > {KERNEL_NAME_PROVIDED}`, linux-image-{KERNEL_NAME_PROVIDED}, linux-
> > headers-
> > {KERNEL_NAME_PROVIDED} and `linux-image-${KERNEL_NAME_PROVIDED}-
> > dbg`
> > 
> > Then, we make `linux-mainline` build all except `linux-kbuild` (if
> > we don't 
> > need cross version). And we could create the similar recipe `linux-
> > kbuild` 
> > that inherits `linux-custom`, but builds only `linux-kbuild` - with
> > ISAR_CROSS_COMPILE="0".
> > 

@Bely
Your commit fb61feff moves merge_config.sh call from linux-custom.inc
to debian/isar/configure.tmpl

The merge_config.sh is very slow in target schroot (seems slower than
the build of the scripts/tools itself), so maybe it should be moved
back to linux-custom.inc to run in host schroot.

> > Of course, such an approach breaks the feature "build everything
> > from one 
> > recipe", but it doesn't require "schroot" workaround and would make
> > build 
> > process more configurable.
- Prototype keeps build everythong from one recipe approach.
> 
> On top, we need a loop in the dpkg class the runs the recipe for
> multiple archs, not just the target one. Then also drop that special
> and
> ugly "-cross" package and just built the kbuild thing for the target
> and
> the builder arch.

- Prototype build using dpkg class without the most linux-custom
schroot customizations. Improvment is ongoing...

What would a beautiful solution to enable a recipe for multiarch in a
generic way? Any ideas? (Specify that target build should run)

> 
> Jan
> 

-- 
Stefan Koch
Siemens AG
www.siemens.com