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

[Pavel Hrdina]

On Tue, Apr 20, 2021 at 03:36:55PM +0200, Andrea Bolognani wrote:
> On Tue, 2021-04-20 at 15:20 +0200, Pavel Hrdina wrote:
> > 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:
> > > > 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.
> 
> Documentation is great and all, but the problem with it is that it's
> extremely easy for it to become outdated as new optional runtime
> dependencies are added; the advantage of having this list stored in
> Meson is that the person who's adding a new optional runtime
> dependency is likely to look around for how the existing ones are
> handled, and thus automatically do the right thing.

I would say the same applies to the documentation. If the person who's
adding a new dependency will "git grep" for any already existing binary
to see what needs to be done they will find the documentation as well.
At the same time there is no guarantee that having it in meson would
make sure that we will not miss any new dependency if it's only
optional.

The only way to make sure the list is not outdated in meson or in
documentation is to add a check which would compare the list with what
we actually have in the code, like for example we do for po/POTFILES.in
to ensure that every source code file using translation is listed there.

I don't see this as a strong argument for having the list in meson.

> The point about libvirt-ci storing all the dependencies is a good
> one, but note that we only keep track of *build time* dependencies
> for projects: that is, once e.g. dnsmasq is no longer required to be
> available in the build environment in order to produce a
> fully-featured libvirt build, we'll simply stop including it. This
> will happen with almost all other optional runtime dependencies too,
> so really the mappings that are maintained as part of the libvirt-ci
> project doesn't solve the issue of keeping track of optional runtime
> dependencies at all.

Good point, but as a starting point libvirt-ci can be used to get at
least build dependencies.

Pavel
-------------- 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/1eccc95e/attachment-0001.sig>