Re: [PATCH v6 1/9] isar-bootstrap-host: disable DISTRO_BOOTSTRAP_KEYS usage

[Jan Kiszka <jan.kiszka@siemens.com>]

On 22.05.19 08:55, Maxim Yu. Osipov wrote:
> On 5/22/19 8:37 AM, Claudius Heine wrote:
>> Hi Jan,
>>
>> On 21/05/2019 18.56, Jan Kiszka wrote:
>>> On 15.05.19 12:11, [ext] claudius.heine.ext@siemens.com wrote:
>>>> From: Claudius Heine <ch@denx.de>
>>>>
>>>> isar-bootstrap-host only supports bootstrapping Debian root file
>>>> systems. Therefore deactivate any DISTRO_BOOTSTRAP_KEYS from other
>>>> distributions.
>>>
>>> Actually not totally true, as I just realized: What about bootstrapping the 
>>> buildchroot from a custom debian repo that was differently signed (e.g. 
>>> because it is a condensed version of upstream)? Seems we do need 
>>> HOST_DISTRO_BOOTSTRAP_KEYS, right?
>>
>> You are right, I haven't considered that case. Well, the next task on the todo 
>> list should probably be to refactor and streamline the isar-bootstrap, and 
>> especially the host bootstrap process and fix those kind of issues while doing 
>> that.
>>
>> There are a lot of possible customization options gained if the current giant 
>> bootstrap function would be split up, similar to how the rootfs system works 
>> in the pre-processing patchset.
>>
>> Maybe it makes sense to also start renaming "host" and "target" to be 
>> compatible with the gcc nomenclature [1] in that patchset. I am a bit 
>> reluctant to do so, because of the breakage involved. But the further we wait, 
>> to more stuff will break downstream.
>>
>> The plan would be to rename all occurrences of "host" to "build" and "target" 
>> to "host". That would lead to the following recipe changes:
> 
> 
>> "buildchroot-host" -> "buildchroot-build"
>> "buildchroot-target" -> "buildchroot-host"
>> "isar-bootstrap-host" -> "isar-bootstrap-build"
>> "isar-bootstrap-target" -> "isar-bootstrap-host"
> 
> 
>> I am on the fence of that change. Correctness vs. no-breakage
>>
>> Any comments about that?
> 
> I would prefer to avoid such a renaming taking into account needed efforts and 
> possible confusion for current Isar users.
> 

Is that build/host scheme then also in line with Debian naming? Then there will 
be eventually no way around it anyway. But we really need to do this thoroughly, 
specifically /wrt to user-visible interfaces, so that it will be one cut only.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux