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

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

On 22.05.19 09:31, Claudius Heine wrote:
> Hi Jan,
> 
> On 22/05/2019 09.02, Jan Kiszka wrote:
>> 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.
> 
>  From dpkg-buildpackage(1):
> 
> [...]
>         -a, --host-arch architecture
>                Specify  the  Debian  architecture  we  build  for (long option 
> since dpkg
>                1.17.17).  The architecture of the  machine  we  build on  is  
> determined
>                automatically, and is also the default for the host machine.
> [...]
>         --target-arch architecture
>                Specify  the  Debian architecture the binaries built will build 
> for (since
>                dpkg 1.17.17).  The default value is the host machine.
> [...]
> 

Then the current naming scheme is already accurate for Debian.

Jan

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