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

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

On 22.05.19 13:39, Claudius Heine wrote:
> On 22/05/2019 13.35, Jan Kiszka wrote:
>> 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.
> 
> No? That is not how I read that documentation. "Host" is what we build for and 
> 'Target' is what the binaries we build generate code for (which makes only sense 
> for compilers)

https://wiki.debian.org/BuildingCrossCompilers

"Nomenclature

TARGET is the architecture the compiler builds code for. HOST [...] is the 
architecture the compiler runs on."

Mapping that on our buildchroots: buildchroot-host is where the compiler runs 
natively, buildchroot-target is where it runs on the target architecture. Thus, 
no need to flip anything.

Jan

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