Re: [PATCH 2/2] sbuild: do not build arch all packages on cross

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

On 29.04.26 13:40, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Wed, 2026-04-29 at 13:26 +0200, Jan Kiszka wrote:
>> On 29.04.26 13:10, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>> On Wed, 2026-04-29 at 12:55 +0200, Jan Kiszka wrote:
>>>> On 29.04.26 12:53, Jan Kiszka wrote:
>>>>> On 29.04.26 12:47, 'Felix Moessbauer' via isar-users wrote:
>>>>>> Architecture all packages often cannot be built in cross mode, as the
>>>>>> dependencies cannot be resolved in the host architecture. This
>>>>>> especially applies to all packages which split their build dependencies
>>>>>> into Build-Depends-Arch and Build-Depends-Indep. We already have logic
>>>>>> in isar to built DPKG_ARCH=all packages non-cross, but this does not
>>>>>> work for packages that generate both arch specific and arch all binary
>>>>>> packages.
>>>>>>
>>>>>> While sbuild automatically disables builds of arch-all packages on
>>>>>> cross, we previously explicitly overrode this setting. We now change
>>>>>> this by explicitly setting --no-arch-all flag on cross and --arch-all on
>>>>>> non-cross.
>>>>>>
>>>>>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
>>>>>> ---
>>>>>>  RECIPE-API-CHANGELOG.md          | 15 +++++++++++++++
>>>>>>  meta/classes-recipe/dpkg.bbclass |  3 ++-
>>>>>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
>>>>>> index 856da5de..c83c1599 100644
>>>>>> --- a/RECIPE-API-CHANGELOG.md
>>>>>> +++ b/RECIPE-API-CHANGELOG.md
>>>>>> @@ -1001,3 +1001,18 @@ do_copy_boot_files: The recipe isar-image-base is trying to install
>>>>>>  files into a shared area when those files already exists. It happens
>>>>>>  when some files have the same names (e.g., dtb files) for different
>>>>>>  distros.
>>>>>> +
>>>>>> +### No building of arch=all packages when cross building
>>>>>> +
>>>>>> +Architecture all packages often cannot be built in cross mode, as the
>>>>>> +dependencies cannot be resolved in the foreign architecture. This especially
>>>>>> +applies to all packages which split their build dependencies into
>>>>>> +`Build-Depends-Arch` and `Build-Depends-Indep`. We already have logic
>>>>>> +in isar to built `DPKG_ARCH = "all"` packages non-cross, but this does not
>>>>>> +work for packages that generate both arch specific and arch all binary packages.
>>>>>> +
>>>>>> +We now explicitly disable building arch=all binary packages on cross (this
>>>>>> +technically only affects packages that generate arch specific and arch=all
>>>>>> +binary packages). To build the arch=all binary packages of such source packages,
>>>>>> +add an explicit dependency to `${BPN}-native`. Source packages that only
>>>>>
>>>>> That will be fun to find, though likely a rare one. Can't we detect such
>>>>> cases in Isar and add a bitbake dependency from $BPN to -native?
>>>
>>> We could try to parse the ${S}/debian/control file and detect this, but
>>> I guess that doesn't work, as we would have to add the dependency
>>> before running bitbake tasks (a common case is that the debian part is
>>> fetched, hence the task need to run and then it's too late).
>>>
>>>>>
>>>>
>>>> In fact, -native is practically overshooting. We would need a recipe
>>>> target that only build the all package.
>>>
>>> I thought about this as well. We would need a -all variant that is
>>> basically identical to -native but adds the --no-arch-any sbuild flag.
>>> However, this only helps for first-stage dependencies, as the
>>> transitive dependencies still need to be build in -native. Further, we
>>> need to ensure that either -all or -native is built, but not both. This
>>> would need a model similar to the fetch_common_source task. That's a
>>> lot of complexity for a minimal build-time improvement. By that, I
>>> rather would like to avoid this optimization. If we really need it, we
>>> still can add it in the future.
>>
>> The key question is how to ensure that people will find this highly
>> non-intuitive recipe dependency. We need to explain this even harder
>> than the difference between IMAGE_INSTALL and IMAGE_PREINSTALL.
>>
>> BTW, it also affects how recipe writers have to translate their binary
>> output packages into PROVIDES statements. If you do that incorrectly,
>> unconditionally, the mess will only get bigger.
> 
> That's an interesting finding. If you model the PROVIDES correctly, you
> don't have to add the explicit RDEPENDS to the -native variant. This is
> what we should document instead of the -native dependency.
> 

Better test it - I bet there will be further devils in the detail.

> Will do so in a v2, once I have more feedback.
> 

I'm afraid we are not stable with this approach yet.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/b4f295d9-b4c5-4e04-962c-d25545db6070%40siemens.com.