[libvirt PATCH v2 00/21] cleanup meson checks for runtime binaries

[Pavel Hrdina]

On Tue, Apr 20, 2021 at 02:14:59PM +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 20, 2021 at 03:05:26PM +0200, Andrea Bolognani wrote:
> > On Mon, 2021-04-19 at 19:14 +0200, Pavel Hrdina wrote:
> > > Recent attempt to add a lot of meson options to specify different
> > > runtime paths motivated me enough to cleanup this from meson.
> > > 
> > > Changes in v2:
> > >     - split and rework patch 16/17 to address review comments
> > >     - added a new patch to cleanup libvirt.spec.in file
> > 
> > Overall I like this change, if nothing else because it finally cleans
> > up the mess where some optional programs would be detected at build
> > time while others would be detected at runtime, with no apparent
> > reason for going one way rather than the other.
> > 
> > The only concern I have, which is one I have expressed already in the
> > past, is that it will now be harder for users and packagers alike to
> > figure out that they don't have a certain optional program installed:
> > AFAICT, after your patches the only way would be to try using each
> > feature and look out for errors.
> 
> I'd say that running "meson" and looking at its output is a poor
> way for users to learn what the pre-requisites are, both before
> and after this change.
> 
> Ideally we should document the list of packages we depend on.
> We have it sorta documented in the many docker files.
> 
> I wonder if we should include the list of mapping names from
> libvirt-ci as an explicit doc item in README.md or somewhere
> else that could be useful. Or just tell tem to look at the
> dockerfiles. Even if their distro isn't covered, it'll be
> enough info for them to get most of the way there.

Agreed, instead of having it in meson I would also prefer having it
documented somewhere. Ideally we should not document only what optional
programs we use but every single dependency we use ideally with links to
upstream projects and possibly examples of downstream packages which is
as Dan pointed out stored in libvirt-ci.

Pavel

> > Note that said macro would *not* be defined conditionally based on
> > whether the optional program was found at build time: the intention
> > is simply to have a single location where information about all these
> > optional runtime programs are stored, instead of forcing users and
> > packagers to go hunting for them across all of libvirt, potentially
> > missing a bunch in the process.
> > 
> > What do you think?
> > 
> > -- 
> > Andrea Bolognani / Red Hat / Virtualization
> > 
> 
> 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 :|
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20210420/fc13d32e/attachment-0001.sig>