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