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
