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