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

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

On 22.05.19 14:15, [ext] Jan Kiszka wrote:
> 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.
> 

Citing from the wrong wiki, I got confused about this unfortunate nomenclature 
(because of the fuzzy term "host"):

"host means the architecture of produced executable objects, i.e. the 
architecture of the host system where these guest objects will run on (called 
target or sometimes build elsewhere) "
https://wiki.debian.org/CrossCompiling

Given this, we should definitely avoid reusing "host" when doing any renaming. 
It will only make things worse, specifically if some user-facing variable that 
we used to call HOST_SOMETHING now gets different semantic without changing its 
name. One option would be only renaming host->build and dropping "target" from 
the rest.

Jan

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