Re: [PATCH 1/2] add support for derived sbuild chroots

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

On 13.06.23 08:24, Uladzimir Bely wrote:
> On Thu, 2023-04-13 at 07:00 +0000, 'Felix Moessbauer' via isar-users
> wrote:
>> This patch adds support to create derived sbuild chroots to speedup
>> the
>> build process. For packages that share a large set of common build
>> dependencies, a derived sbuild chroot can be created to avoid the
>> overhead of installing all base build-deps on each sbuild invocation.
>>
>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
>> ---
>>  doc/user_manual.md                            | 27
>> +++++++++++++++++++
>>  meta/classes/crossvars.bbclass                | 11 +++++---
>>  .../sbuild-chroot/sbuild-chroot.inc           |  7 ++++-
>>  3 files changed, 41 insertions(+), 4 deletions(-)
> 
> We are going to merge this in near few days in spite of an open
> question left in discussion. The reasons:
> 
> 1. It passes internal CI (dev/fast/full).
> 
> 2. It was useful in case of 'meta-iot2050' downstream for rewriting
> "npm.bbclass" in order not to use buildchroot.bbclass (that is going to
> be deleted with "Imager schroot migration" patchset that is to be
> merged soon too.

To track what I discussed with Baurzhan offlist: I would be good to have
some QA check running when using a derived sbuild chroot that the
package built has all extra packages as part of its Build-Depends so
that we are not create again silently broken debianizations. Any ideas
how to achieve that best, considering also implicit inclusions of the
Build-Depends?

Furthermore, I had a small comment on patch 2.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux