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