On Wed, Apr 29, 2020 at 11:10:41AM +0200, Andrea Bolognani wrote: > On Tue, 2020-03-31 at 15:28 +0100, Daniel P. Berrangé wrote: > > Currently when creating a Dockerfile for a container, we include the > > full set of base packages, along with the packages for the project > > itself. If building a Perl binding, this would require us to install > > the base package, libvirt packages and Perl packages. With the use > > of the "--inherit libvirt-fedora-30" arg, it is possible to have a > > dockerfile that only adds the Perl packages, getting everything > > else from the parent image. > > > > For example, a full Dockerfile for libvirt-go would thus be: > > > > FROM libvirt-centos-7:latest > > > > RUN yum install -y \ > > golang && \ > > yum autoremove -y && \ > > yum clean all -y > > > > Note there is no need to set ENV either, as that's inherited from the > > parent container. > > I marked this for review and then kept forgetting to get around to > it, sorry! > > I like the idea of reusing existing images, as the layering would > result in significant savings when it comes to disk space and fetch > times. > > However, as we discussed in the past, there are two possible > scenarios for subprojects such as libvirt-go: > > * include dependencies for both libvirt and libvirt-go, then build > both projects in the resulting container; > > * include dependencies for libvirt-go along with distro-provided > packages for libvirt, and only build libvirt-go. > > This would cover the former case, but not the latter one. And, if I > remember correctly, libvirt-go was one of the projects that would > benefit more from the latter, because it's supposed to be buildable > against various versions of libvirt. > > 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. > 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
