From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6690944878080163840 X-Received: by 2002:ac2:593a:: with SMTP id v26mr43291273lfi.64.1558529419484; Wed, 22 May 2019 05:50:19 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:12cd:: with SMTP id 74ls248024ljs.4.gmail; Wed, 22 May 2019 05:50:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqxqTG2o8hM2iJAboyUh80yS3QUuDr3v46lDLxcw8Dw97Mgouw3n48HPf3I1NI2/CKLBZxLW X-Received: by 2002:a2e:9116:: with SMTP id m22mr6196223ljg.12.1558529418870; Wed, 22 May 2019 05:50:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558529418; cv=none; d=google.com; s=arc-20160816; b=TSoyZz+N62IREX7VnJ/MrdPjS7qsB3NHJd2/tJlT2LDHfZyLQA33Q0dYFEwovpGQRO OxOcvNEwTyNuh+Nir7+eRVYFwQA47as8O4HsiuxpRe9SHvwnIDFKwYy+RIex40TzYtbS 6BzO8GJtatEVT1MjAAjNqc6rDGIP+w0JWzNdVHV30BYFz3d+Y0QgGwLKHdWjVaidU8Hl QCLkkTIxosWq5k+FGrEEiSdCpAhYFIlfU433/QwiRS1LcJOss8F+vZrXFusAvnrKeMq3 glH3PRt5MwC5qi0DGEpugFkwTxGuL1OHsWxM0/o/pIm/MQPNoFA9wqfMpFo3l/KPT65g 6wHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:references:cc:to:from:subject; bh=h2HWzIvLz8oVjqIjPRugMg8ALQ9tE3jT7XJZBTwQus4=; b=cRxP6nKre+/svrTxSwWqF+4HF2Q98KX5Vez1dy05sBvehk09RKynsuWmlL7ZfwtMDj yI3nQd6GnaVxHL2NKFx9ofSalQzqrBWYEnQXhKQ1leQPSrUXxlvGwahZs06JSWlWAaws y26ylX6eRShaKFZ2/0ENYn847WJUAKKPGckHFhXZXXg7K+9gB7b/kRTfDY4Fv/SgyLqx AvXC8pJmshtl4pkN3N3a23UCPJbGxr+3dn79qShFfQ14Jc4B7IpjTF4gdOvFyfmqf054 PoNfGxFqRNDFXLxMmyhob3/D2Dr/vvavgxbC/c+B49fcJztYCGBclhcYRfrCYvL0Z5pz +/Bg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id m17si2303701ljg.4.2019.05.22.05.50.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 05:50:18 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id x4MCoHXr012049 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 May 2019 14:50:17 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x4MCoHjr011409; Wed, 22 May 2019 14:50:17 +0200 Subject: Re: [PATCH v6 1/9] isar-bootstrap-host: disable DISTRO_BOOTSTRAP_KEYS usage From: Jan Kiszka To: Claudius Heine , "Maxim Yu. Osipov" , isar-users@googlegroups.com Cc: Claudius Heine References: <20190515101149.22187-1-claudius.heine.ext@siemens.com> <20190515101149.22187-2-claudius.heine.ext@siemens.com> <3745f4ba-e3c9-4d59-22e4-9746c6497f6b@siemens.com> <80d56fc5-00fa-5508-7fb1-976b4b5c61db@siemens.com> <514b7749-f950-ec44-b5a2-affcbfb91e6d@siemens.com> Message-ID: <0a86b0e8-8b57-d2c7-998c-d099952af86b@siemens.com> Date: Wed, 22 May 2019 14:50:18 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: AcMjNE4BiWgO 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 >>>>>>>>> >>>>>>>>> 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