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

[Moessbauer Felix <felix.moessbauer@siemens.com>]

On Wed, 2023-06-21 at 14:42 +0200, Henning Schild wrote:
> 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.

How about merging just this patch, but not the example?
I currently cannot offer to provide a better example or CI integration.
Sorry.

If someone wants to implement it, feel free to send a patch.

Felix

> 
> Henning
>  
> > Jan
> > 
>