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

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

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).

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/09a97392-a6f3-4329-a5d3-af39a45d6c87%40siemens.com.