[libvirt-jenkins-ci PATCH] guests: allow for container image inheritance

[Andrea Bolognani]

On Wed, 2020-04-29 at 10:21 +0100, Daniel P. Berrangé wrote:
> On Wed, Apr 29, 2020 at 11:10:41AM +0200, Andrea Bolognani wrote:
> > So what I think we need is an additional flag that can be used to
> > choose one of the two possible behaviors. This wouldn't be limited
> > to the Dockerfile generator, since (unlike inheritance) it can apply
> > also to VM management.
> 
> I think this problem is tangential to container inheritance and so
> doesn't need to be dealt with here.
> 
> Instead, it should be solved by simply defining another project
> "libvirt-devel", or "libvirt-dist" which pulls in the pre-built
> distro packages for libvirt.

Yeah, the additional projects introduced in the patch you posted
yesterday cover this use case quite nicely without having to
introduce any additional behaviors in lcitool.

> > As an additional point, we really need to figure out a good way to
> > store dependencies between projects into lcitool itself, so that you
> > can tell it that you're interested in building eg. libosinfo and it
> > will automatically take care of making osinfo-db-tools and osinfo-db
> > available to you, either by installing the binary packages or their
> > build dependencies. This is not a strict requirement for container
> > inheritance, I think, but the more we go on the more this limitation
> > is becoming painful.
> 
> I'm not really experiencing this as a painpoint from the container CI
> side.

Well, that's because you know what the dependencies between various
projects are by heart ;)

But again, the introduction of project variants that install the
distro-provided dependencies, along with the proper integration with
GitLab CI, will mitigate this concern to a large degree.

-- 
Andrea Bolognani / Red Hat / Virtualization