Re: [PATCH 0/2] Rework deployment of image artifacts

["'Quirin Gylstorff' via isar-users" <isar-users@googlegroups.com>]

On 4/17/26 5:05 PM, Jan Kiszka wrote:
> On 17.04.26 16:39, 'Jan Kiszka' via isar-users wrote:
>> On 17.04.26 16:15, Zhihang Wei wrote:
>>>
>>>
>>> On 4/16/26 18:01, Jan Kiszka wrote:
>>>> On 16.04.26 17:51, Jan Kiszka wrote:
>>>>> On 16.04.26 17:42, Zhihang Wei wrote:
>>>>>> Applied to next, thanks.
>>>>>>
>>>>> I am repeating myself: We broken the deployment API in v1.0. This series
>>>>> is breaking it once more, just differently (and rather unhandy for many
>>>>> downstream users).
>>>>>
>>>>> Are we truly sure now that this is the FINAL solution, or do we plan for
>>>>> n more API breakages?
>>>>>
>>>> But let's a assume we keep it like this:
>>>>
>>>> What is the plan for a v1.0.1 hotfix release? I'm seeing other patches
>>>> being merged. Some would qualify to be part as well, another one is
>>>> harmless but not a hotfix. So I'm asking before things possibly move on
>>>> further. At least some users here are waiting to adopt v1.0.x.
>>>>
>>>> Jan
>>>>
>>> We have tested the prefixed DTB approach on our downstreams and it
>>> works without major issues.
>>
>> You likely have nothing like the deployment scripts for LAVA
>> (isar-cip-core, xenomai-images). It breaks them, and we need extra logic
>> because of the mangled names and paths.
>>
>>>
>>> Regarding splitting TMPDIRs: this would break at least one of our
>>> downstreams. We have a setup with two multiconfigs — one for rescue
>>> (with its own rootfs, kernel, etc.) and another regular one which
>>> depends on the rescue one and needs to consume its deployed artifacts.
>>> Splitting TMPDIRs is not viable in this case.
>>>
>>
>> This has already been identified as problem, yes. OE does not use it
>> either, only few downstreams. We are apparently overusing mc: or the
>> deployment folder here.
>>
>>>
>>> As for the release plan: we would like to target v1.1 rather than a
>>> v1.0.1 hotfix, with the API expected to remain stable for some period.
>>
>> We must fix this soon or 1.0 will remain a no-go version. It will then
>> happen the opposite of what "1.0" was aiming at: to signal maturity.
>>
>>> I propose that if a final solution can be found quickly, we hold v1.1
>>> until it is merged. Otherwise, v1.1 should be based on the prefixed DTB
>>> patch.
>>>
>>> We do have a new proposal for the "final solution". Let me send it
>>> under v6 DTB discussion.
>>>
>>
>> I'm looking into it.
>>
>> Jan
>>
> 
> Just to make it clear (again), this is how OE deploys DTBs to images:
> 
> build/tmp/deploy/images/qemusdc2/devicetree/*.dtb
> 
> Didn't check yet, but there might even unfold the new subdirectory
> structure (by vendor, mostly) under that folder. So this renaming here
> is not getting us better aligned (to be fair: we were not aligned before).

 From the history of 
https://git.openembedded.org/openembedded-core/log/meta/classes-recipe/kernel-devicetree.bbclass 
the kernel recipe name was added to the devicetree file.


it looks like the devicetree folder is created by 
https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/devicetree.bbclass 
to avoid a clash with the device tree deployed by the kernel.

Quirin
> 
> Jan
> 

-- 
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/a1e72665-6763-4190-a9e6-be2b98e67161%40siemens.com.