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

[Claudius Heine <claudius.heine.ext@siemens.com>]

On 22/05/2019 14.50, Jan Kiszka wrote:
> 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.

With my patchsets we could probably even drop 'build', 'host' and 
'target' from the recipes all together and just go for the build host 
tupel. For instance:

"buildchroot-host-amd64-arm" -> "buildchroot-amd64-arm"
"buildchroot-target-arm" -> "buildchroot-arm"
"isar-bootstrap-host-amd64-arm" -> "isar-bootstrap-amd64-arm"
"isar-bootstrap-target-arm" -> "isar-bootstrap-arm"

That would only affect the PN variable in those recipes, the file names 
would probably be 'isar-bootstrap-build.bb'/'isar-bootstrap-native' 
(which is what yocto is using to avoid 'build') and 
'isar-bootstrap-host.bb'/'isar-bootstrap.bb'.

For the variables just renaming 'HOST_*' stuff to 'BUILD_*' stuff would 
be ok, but maybe a bit confusing, because 'build' might be a bit vague 
there. How about 'NATIVE_*'?

regards,
Claudius

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de