Re: [PATCH v3 5/6] sdk: Inject sysroot path when calling relocated toolchain

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

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