On Wed, Apr 29, 2020 at 08:52:06PM +0200, Andrea Bolognani wrote:
On Wed, 2020-04-29 at 11:38 +0100, Daniel P. Berrangé wrote:
Thus this introduces a new project "libvirt-minimal" which lists the bare minimum dependencies required to build libvirt.
I don't like the name libvirt-minimal because it appears to follows the convention used for actual libvirt-based projects such as libvirt-glib.
What about libvirt+minimal, following the project+variant convention used for all MinGW builds[1] and in the past for libvirt+website?
Some projects also wish to have the ability to build against the distro provided libvirt instead of the latest git master, and for this purpose a "libvirt-dist" project is defined which pulls in the package needed for building against the distro libvirt.
I don't like this name either :)
One reason is the same detailed above, but there's another one which is tied to semantics: in lcitool, "$project" has always been used to mean "the list of packages necessary to build $project from source".
This is the case for all the projects that exist today[2] and even for libvirt+minimal, but this one is different: in this case, libvirt-dist means "the list of packages necessary to build a project that *depends* on libvirt from source". That's quite different.
I think a better approach would be to once again use variants: for example, if you wanted to build libvirt-python against the version of libvirt included in the OS, instead of having something like
# libvirt-python.yml --- packages: - python3 ...
# libvirt-dist.yml --- packages: - libvirt
which is then used like
$ lcitool dockerfile $OS libvirt-dist,libvirt-python
you'd have
# libvirt-python+dist.yml --- packages: - libvirt - python-3 ...
which is used like
$ lcitool dockerfile $OS libvirt-python+dist
This would achieve the same result with less typing and without subverting the existing semantics.
This results in defining the combinatorial expansion of project sets which just looks like unecessary duplication & work to me. It also gives different syntax for configuring a container to build from git vs dist. There is only ever one project here "libvirt-project" and nothing about it is is changing, except for which "libvirt" it is being built against. It supports any libvirt, whether a full git build or a minimal git build, or a distro build or some other build: $ lcitool dockerfile $OS libvirt,libvirt-python $ lcitool dockerfile $OS libvirt-dist,libvirt-python $ lcitool dockerfile $OS libvirt-minimal,libvirt-python We could call it "libvirt+dist" instead "libvirt-dist" if we want
Another nice property of this approach is that it naturally extends to cover projects that depend on more than just libvirt: for example, we could have
# libvirt-dbus+dist.yml --- packages: - libvirt - libvirt-glib ...
for use in libvirt-dbus CI.
I think that's a downside not a plus, because it makes the combinatorial expansion even bigger. 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 :|