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