On Thu, Jul 18, 2019 at 03:05:16PM +0200, Andrea Bolognani wrote: > 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. I probably shouldn't have picked the perl bindings on reflection, because they can't be built without the libvirt from git. Python / go bindings would be better as they aim to keep buildable with historic versions. > > 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. We don't need to teach it about relationships between projects in an explicit sense, in fact it could be helpful if we don't teach that. Rather we just need two lists of package. One minimal set for the chain build scenario, and one extra set for the self-contanied build scenario. eg --- chain_build_packages: - python2 - python2-devel - python2-lxml - python2-nose - python3 - python3-devel - python3-lxml - python3-nose isolated_build_packages: - libvirt Doing it with package lists would give us flexibility. For example, for python where we want to test against many libvirt versions, we have the opiton to list many versions using my virt-ark repo for example --- chain_build_packages: - python2 - python2-devel - python2-lxml - python2-nose - python3 - python3-devel - python3-lxml - python3-nose isolated_build_packages: - libvirt-ark-2_0_0 - libvirt-ark-3_0_0 - libvirt-ark-4_0_0 > 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? Having containers per project looks reasonable, especially as we can now more easily automate their creation so it isn't such an admin burden as before. Probably makes sense to still keep it all under the libvirt org, since we're still reusing the libvirt jenkins toolchain. We'd just need a project specific name prefix on each 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
