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

[Henning Schild <henning.schild@siemens.com>]

Am Mon, 19 Jun 2023 07:58:14 +0200
schrieb "'Jan Kiszka' via isar-users" <isar-users@googlegroups.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?

As said by others that is kind of hard and the simplest would be a
double check in a "normal" sbuild where no extra packages are
installed. But i really do not see that as a big problem. Missing build
deps are unfortunate but not a big deal for anyone to resolve quickly
... should they ever surface because the build env for a given
code-base is ever brought on such a "minimal" build env.

In the past we shared a buildchroot and build order or parallel builds
of packages with conflicting build-depends would cause sporadic errors
that used to be hard to understand. Now nothing is shared ... if one
forgot a tool or library that is trivial to understand and fix.

IMHO not worth the effort. The feature is useful and the potential
problems rather harmless.

> Furthermore, I had a small comment on patch 2.

I kind of dislike that example but like the effort to put the new
feature under CI and present it with an example and test case to begin
with.

Henning
 
> Jan
>