Re: [PATCH 1/1] dpkg-raw: make sure do_install gets called for -compat/-native builds

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

On 13.09.24 12:52, Hombourger, Cedric (DI CTO FDS CES LX) wrote:
> On Fri, 2024-09-13 at 12:45 +0200, Jan Kiszka wrote:
>> On 13.09.24 10:29, Hombourger, Cedric (DI CTO FDS CES LX) wrote:
>>> On Fri, 2024-09-13 at 10:08 +0200, Jan Kiszka wrote:
>>>> On 12.09.24 17:11, 'Cedric Hombourger' via isar-users wrote:
>>>>> With sources being built only once, do_prepare_build (and its
>>>>> dependencies)
>>>>> are skipped when building -compat or -native packages. This
>>>>> unfortunately
>>>>> means that do_install is not executed and is causing the
>>>>> package
>>>>> build
>>>>> to fail as the install step is not finding any files in
>>>>> ${PP}/image. To
>>>>> avoid changing how do_install is scheduled in the normal case,
>>>>> it
>>>>> is simply
>>>>> added as an extra dependency to do_dpkg_build to make sure it
>>>>> gets
>>>>> executed
>>>>> prior to the build of the binary package.
>>>>
>>>> What is the use case for raw-compat and -native? Are you actually
>>>> having
>>>> a case with different binaries then?
>>>
>>> For my specific case, I had wished -native would not be built
>>> because
>>> my dpkg-raw package has DPKG_ARCH set to "all". In that case, we
>>> should
>>> not have a separate build for -native
>>>
>>> The issue will occur for any "dpkg" package being built for -native
>>> when it DEPENDS on a "dpkg-raw" package because our native class
>>> automatically changes all dependencies to -native
>>>
>>
>> Then stub-out the other variants, make them depend on the BPN
>> package,
>> but do not further foster their build.
> 
> My "dpkg" recipe is clean, it has a DEPENDS clause with only BPN names
> But we have multiarch [1] suffixing each of our DEPENDS with -native
> when built for -native
> 
> Or maybe I am not understanding your proposal? I am pretty sure we have
> a bug in Isar. I can build a test case if the illustration with
> example-raw is not sufficient / convincing

Yes, this is an issue in isar. But I would address it there by not doing
anything in <raw>-native/compat targets, only making them depend on
their base target. IIRC, we already have such a case deep in the kernel
build.

Rebuilding the same thing is wrong.

Jan

-- 
Siemens AG, Technology
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 on the web visit https://groups.google.com/d/msgid/isar-users/fc4dd743-2415-4076-85eb-8c6b73086bab%40siemens.com.