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

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

Am Wed, 21 Jun 2023 21:22:30 +0800
schrieb 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.

I think that would even be acceptable. It is hard to demo really,
because if you do it to only one package it looks rather useless and
the demo does not make too much sense.

But in that case please send a v2 because you mention the samefile
example in the docs.

Henning

> If someone wants to implement it, feel free to send a patch.
> 
> Felix
> 
> > 
> > Henning
> >    
> > > Jan
> > >   
> >   
>