From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6806948680239677440 X-Received: by 2002:a05:600c:228e:: with SMTP id 14mr31298462wmf.17.1600688830883; Mon, 21 Sep 2020 04:47:10 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:1b86:: with SMTP id b128ls6478241wmb.3.canary-gmail; Mon, 21 Sep 2020 04:47:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzE1mCkjcI5Y8wezgWGg/xhXLFaUbu/xGJ6UhWYV7H5DhNaH4g4w8HwzjmJzQwAZXHMuIJT X-Received: by 2002:a05:600c:2f8f:: with SMTP id t15mr30685506wmn.41.1600688829795; Mon, 21 Sep 2020 04:47:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600688829; cv=none; d=google.com; s=arc-20160816; b=JYxc8IPL1eOLcyVSrZhGt7tAVd7FSSSzfNFePluH0+o2M6LoLiYClTt57ockm5xHbu M6ZGJSdOcjK055FuBnoaWEsUVKDtZBQIVNHohARJ32bbPSp+EGOCgLpfD6515uhIctLN wGB1hk81S5kUlXnHSufn89CkX2wqpJ0RgFmlBoMVquadY4LEcxka/W3xDRxZVBg9jqmc FPS1fnyJnachrE9XXXd1MXuZq+v8VePVzgBj6Z45ypquNDoL0il1h6itHJmjmYFEUP56 6rBosYYaknIbjcx7f3sK847N7qM2ypTBjrLyLdwSJrJh+Ll4n8yvJQKbrTgnykU5QQGk bjjQ== 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:from:references:to:subject; bh=koNWAHb7pQXfox/G/A0go5JvfdqacB6DmdKIr7t2+CI=; b=mukrc0JvT7+nA4adC5CjeZ7u/qzkrnezKg+4FEKiluTCXCbqNrgvr8GUnRGRMPFVi/ 0vTPI3e0uMUIStloSlBS3kAxgXQB8uBWEfb7wsgQ7vN3szqvOActu1gwlJ6K5YRrMNet JNwXO1Z/kF68HK+m7WtklWK7EYhzV4NJGt0l0XQDzg9fCl9sjXTWsv1b+UsbJmAxE2R7 3GNK9b+3SpkWoJx5EA+0lVh1rgH1/FTWjJq7Yw4WO1O+Elk/Iy122VxFt1gJGZoEJ+1B k9BxuishsOYy4nTvdEHaOHgW3jbc0AFLRFEzv+W7y6jqFfqQFGje1mEd8C7DDndGoJ6k zWvw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id h11si257228wrr.3.2020.09.21.04.47.09 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Sep 2020 04:47:09 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 08LBl92I026691 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 21 Sep 2020 13:47:09 +0200 Received: from [167.87.4.147] ([167.87.4.147]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 08LBl7Cn003921 for ; Mon, 21 Sep 2020 13:47:08 +0200 Subject: Re: [PATCH v3 5/6] sdk: Inject sysroot path when calling relocated toolchain To: isar-users References: <53614bba184fb544be69eacd7a90efffa8d319a6.1585394686.git.jan.kiszka@siemens.com> <20200921100523.GN16317@yssyq.m.ilbers.de> From: Jan Kiszka Message-ID: <71081f79-7ab1-abf7-965a-6cbaf1aec755@siemens.com> Date: Mon, 21 Sep 2020 13:47:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20200921100523.GN16317@yssyq.m.ilbers.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: F8H5SUGOZh3y On 21.09.20 12:05, Baurzhan Ismagulov wrote: > On Mon, Sep 21, 2020 at 11:27:32AM +0200, Jan Kiszka wrote: >> Still pending. This is part of several product layers by now, and I only >> have positive feedback on the usability of the generated SDK so far. Can we >> move forward? > > Here we have to agree on the chroot approach and the way of shipping isar-apt. > > Regarding dropping chroot support: While I welcome the Yocto-like SDK which is > familiar for the Yocto developers, chroot is currently the official Debian way > of building [1]. With Debian implementing multiarch despite being alone in it > and many Debian developers actively disliking non-Debian building, we can't > truly bridge the two by dismissing the Debian way of building in Isar. Both > approaches clearly have their respective advantages and followers, and I think > we should keep both, for developers and production. Declaring the one way as > preferred doesn't help making friends in the other camp, either. We are not dropping the chroot model at this stage. We can keep it longer, but I'm afraid it may eventually bitrot as it remains a niche scenario. The true debian way is pushing all results and the a debian snapshot into own repos that people who like to build inside debian can pull from. An SDK as we generate it does not serve the expert scenario, and building inside a chroot is surely not for beginners due to all the complication with the outer world. > > Regarding dropping isar-apt: Debian is about tools that facilitate different > workflows without imposing One True Way. The strength of shipping isar-apt is > in the developer's ability to install packages afterwards that maybe were not > necessary in the beginning or are not interesting for the most developers. > Taken from this perspective, requiring an SDK rebuild for a new package is > waste of time, especially if different groups are responsible for that and if > further packages are going to be needed shortly afterwards. > > So, I'd like to see how we address these issues with this SDK improvement. If > there are specific problems (e.g., bloat), maybe we could make stuff > configurable, etc., but not break the existing use case outright. I can keep isar-apt opt-in for the time being, expect v3 soon. But my vision remains SDK_INSTALL for this purpose (including chroot), in the future maybe more automated. Blinding shipping the complete isar-apt is, well, a very simplistic approach to the problem. Jan > > 1. https://wiki.debian.org/sbuild > > With kind regards, > Baurzhan. > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux