[libvirt-ci PATCH] guests: introduce libvirt-dist and libvirt-minimal projects

Andrea Bolognani abologna at redhat.com
Wed Apr 29 18:52:06 UTC 2020

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[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
    - 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.

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.

What do you think?

> +++ b/guests/vars/mappings.yml
> +  libvirt-devel:
> +    rpm: libvirt-devel
> +    deb: libvirt-dev
> +    pkg: libvirt

The mapping should be called just "libvirt".

[1] Applying this convention to MinGW builds is increasingly
    inaccurate now that we have proper multi-arch support, and in
    fact at least at the Dockerfile generator level we've gotten
    away with this convention; eradicating it completely is something
    that I hope I'll be able to spend time on in the near future.
[2] Except for base, blacklist and jenkins, but those are internal
    projects which are never exposed to the user so they don't need
    to follow the rules as strictly :)
Andrea Bolognani / Red Hat / Virtualization

More information about the libvir-list mailing list