RE: [PATCH v4 1/3] module.inc: fix kbuild dependency

["Schmidt, Adriaan" <adriaan.schmidt@siemens.com>]

Kiszka, Jan (T CED), 16. Mai 2024 08:21:
> On 16.05.24 08:15, 'Jan Kiszka' via isar-users wrote:
> > On 16.05.24 07:21, 'Jan Kiszka' via isar-users wrote:
> >> On 15.05.24 23:28, Schmidt, Adriaan (T CED EDC-DE) wrote:
> >>> Kiszka, Jan (T CED), Sent: Mittwoch, 15. Mai 2024 19:42:
> >>>> On 15.05.24 17:07, Anton Mikanovich wrote:
> >>>>> 14/05/2024 17:15, 'Adriaan Schmidt' via isar-users wrote:
> >>>>>> This achieves two things:
> >>>>>>
> >>>>>> * Module builds now depend on linux-headers-*-native as build
> dependency.
> >>>>>>    This is a minimal API change compared to the previous linux-
> headers-*.
> >>>>>>    The dependency on the new linux-kbuild is kept hidden in
> >>>>>> linux-custom.inc
> >>>>>> * Remove the unconditional building of native kbuild when it is
> >>>>>>    not needed, i.e. when we're not actually cross-building a module
> >>>>>>
> >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>> Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> >>>>>
> >>>>> Hello Adriaan,
> >>>>> This will fail for distro kernels because linux-distro.bb recipe do not
> >>>>> provide
> >>>>> -native package.
> >>>>
> >>>> Does it fail (spoiler: it does not for me) or do you suspect it may
> fail?
> >>>
> >>> It fails in non-cross cases (amd64 target on amd64 host), regardless of
> the
> >>> value of ISAR_CROSS_COMPILE, with "Nothing PROVIDES 'linux-headers-amd64-
> native'".
> >>>
> >>> The patch below fixes it, by making the distro kernel dummy recipe
> provide it.
> >>> Although it should also be covered by multiarch.bbclass and your commit
> >>> 5c2299c718fa1548057d250318df5bddfea8e2b5, because that seems like a case
> where
> >>> we'd want to drop the '-native' from the dependency.
> >>> Maybe we need to examine the condition here...
> >>>
> >>> Adriaan
> >>>
> >>> ===
> >>> diff --git a/meta/recipes-kernel/linux/linux-distro.bb b/meta/recipes-
> kernel/linux/linux-distro.bb
> >>> index 13b8dc7e..16673b67 100644
> >>> --- a/meta/recipes-kernel/linux/linux-distro.bb
> >>> +++ b/meta/recipes-kernel/linux/linux-distro.bb
> >>> @@ -16,3 +16,5 @@ python() {
> >>>      if d.getVar('KERNEL_HEADERS_PKG'):
> >>>          d.appendVar('PROVIDES', ' ' + d.getVar('KERNEL_HEADERS_PKG'))
> >>>  }
> >>> +
> >>> +inherit multiarch
> >>> ===
> >>>
> >>
> >> This makes sense as linux-distro is a dummy package to please bitbake,
> >> an it does not generate and debian packages, thus does not inherit
> >> multiarch via dpkg-base.
> >>
> >> The reason why multiarch does not help us on example-module side is that
> >> we only append -native to dependencies, we do not remove it anywhere
> >> because we assume hat multiarch will augment PROVIDES with a -native
> >> target when there is no need for a separate one.
> >>
> >
> > In fact, we are also dropping -native from DEPENDS, in the anonymous
> > python block of multiarch.bbclass. Maybe we rather have an ordering
> > issues of all the magics?
> >
> 
> Ah, no, needed to read my own comment more carefully again: that removal
> is only for the case of enforced emulated builds, not for natural native
> ones.

Yes. I also had to read that twice ;)
And I think that's still the right way:

- if the native and "normal" package are the same, the "normal" recipe
  PROVIDES -native. And with v5 that's fixed for linux-distro.bb
- if the native and "normal" packages differ, but conditions (enforced
  emulated build) mean that we need "normal" even though the recipe DEPENDS
  on native, we change the DEPEND side. As it is currently.

Adriaan

> Jan
> 
> --
> Siemens AG, Technology
> Linux Expert Center