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

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

On Fri, 2022-11-18 at 18:11 +0100, Stefan Koch wrote:
> 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'll send a v2 patchset later... That uses build profiles, now.
> 
> > 
> > > 
> > > 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.
The .config is now reused from first build case now. So merge_config.sh
needs not to be rerun anymore.
> 
> > > 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...
Finished... A loop runs the default build and optionally when appending
"target" it creates the kbuild binaries for the target. When appending
"host", the ugly -cross package with invalid traget arch will not be
created - but instead a regular kbuild package with host architecture
will be created.
Just append "target" and/or "host" to ISAR_BUILDS in the recipe that
includes linux-custom.inc
> 
> What would a beautiful solution to enable a recipe for multiarch in a
> generic way? Any ideas? (Specify that target build should run)
> 
> > 
> > Jan
> > 
> 

Merry Christmas and a Happy New Year 2023...