On Thu, 2019-07-18 at 13:35 +0100, Daniel P. Berrangé wrote: > On Thu, Jul 18, 2019 at 02:20:34PM +0200, Andrea Bolognani wrote: > > self.projects = [ > > + "libosinfo", > > "libvirt", > > + "osinfo-db", > > + "osinfo-db-tools", > > ] > > We get away with this single container for libosinfo we don't have > any dependancies between components. It doesn't work in general > though. > > ie the build deps for libvirt-perl skip 'libvirt' because they > assume we already chain built libvirt in the CI. This doesn't > happen except in Jenkins CI though. Yeah, that's a good point. > We've never created a solution for fully populating deps such > that the system is self-contained and doesn't need to chain > build other projects first. I guess we would need basically an alternative mode where you tell lcitool to make the resulting guest or container image entirely self-contained... And in order to do that we'd also need to teach it about relationships between projects, which is something that up until now we have managed to live without. Even once we have that in place, though, the two modes can't quite live side by side in the same container, so a project like for example virt-manager will not be able to use the libvirt container images but would have to prepare its own (using self-contained mode)... So perhaps we should not even consider merging this even though we could still get away with it in this specific case, and instead have the libosinfo project set up their own set of tailored container images from day one? -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
