[libvirt-ci PATCH] guests: introduce libvirt-dist and libvirt-minimal projects
Daniel P. Berrangé
berrange at redhat.com
Thu Apr 30 11:17:38 UTC 2020
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
> What about libvirt+minimal, following the project+variant convention
> used for all MinGW builds 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 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
> - python3
> # libvirt-dist.yml
> - libvirt
> which is then used like
> $ lcitool dockerfile $OS libvirt-dist,libvirt-python
> you'd have
> # libvirt-python+dist.yml
> - 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
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
> - 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.
|: 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 :|
More information about the libvir-list