From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6806948680239677440 X-Received: by 2002:a05:6512:707:: with SMTP id b7mr12667689lfs.457.1600682728243; Mon, 21 Sep 2020 03:05:28 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:651c:93:: with SMTP id 19ls1579324ljq.4.gmail; Mon, 21 Sep 2020 03:05:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxBLYEMtUCN8Yz89Gf4LZ1rci3gKlXc4c2Vuqfqf/SK3QF80wvTRArrWAhSwZ/oiqN5J2iV X-Received: by 2002:a2e:9815:: with SMTP id a21mr922644ljj.311.1600682727018; Mon, 21 Sep 2020 03:05:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600682727; cv=none; d=google.com; s=arc-20160816; b=q+z57Y1hLHcp3uow3CxI3qhF+TVKoXEjIQYltRkYfc7enp6AwLyd5nzOwA6jeLeESW +XIlthaiw9Oag6rVmkLqZghQqrjreqwkNzFRppALp6H4Bu1DzTjXrJgK+/myiLg6nO67 I1yJo8+sn1ucc0a4fryVkIM5uIcc6kvzqnD5O1ouvpojM74SrTETAEwvfvfFs2Yv+jel lFEYqtoyKNvoKqiZ9Uuy1q4HIv+9GD1N25+A0ADrLUf7vII8CHeVryMZZgLj1sCkWfcE d/x7hCd5/7gqHAApKYYBq2Hs3a8fQGgnNjRZEWwmE/WF7PCo8QBvLBgNCOtkUpEi0ZMt u4mA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=nspVegckVHTR+qCCFq9XVh9jVCauTSBpKeEXX9UBHuo=; b=vL3hj7kxfM1p50vhpWVaL24PbB0eDIqL/oWHTQQQzCk0jT2nq71xgYpHJFoHmW1tpF lKe9O4Ro+gqR+mlYaxccwqRLk+Kr0TGUANCx0C6lsmv0D9Sb8O8Qpuxj6aYEHK2XZTCc W12lBcluqUYXGDtuty5yzV+o9QLgQ+U9fK4QrbXTYD24y1r7bG9PDP58jAx9fWH02IBP wQIzKyUcFVa6iozd/1Wm/kXZupsycffmeqs3MVwfLFfV0fKeokyPywaOa4akHcac/KGx SyZTyEkC+vwLHmzAUON0FMx9FqMP6qsqj43pvz2EPbH27ju+U+pwsCJuru3AIeNGmSXR ywdA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id f12si379158lfs.1.2020.09.21.03.05.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 21 Sep 2020 03:05:26 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 08LA5N1t026456 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 21 Sep 2020 12:05:25 +0200 Date: Mon, 21 Sep 2020 12:05:23 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCH v3 5/6] sdk: Inject sysroot path when calling relocated toolchain Message-ID: <20200921100523.GN16317@yssyq.m.ilbers.de> Mail-Followup-To: isar-users References: <53614bba184fb544be69eacd7a90efffa8d319a6.1585394686.git.jan.kiszka@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: MTybxOIuM9Sq 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. 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. 1. https://wiki.debian.org/sbuild With kind regards, Baurzhan.