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

[Daniel P. Berrangé]

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 :|