On Fri, 2020-11-20 at 17:31 +0100, Pavel Hrdina wrote:
On Fri, Nov 20, 2020 at 04:38:20PM +0100, Andrea Bolognani wrote:
> If you did that, then you wouldn't have simplified meson.build much
> while at the same time you'd have ended up with a far less nuanced
> check that does not catch scenarios ranging from the command simply
> not being installed on the build machine to the package not being
> available, perhaps temporarily, for the specific Linux architecture
> in use. Doesn't really sound like an improvement to me.
I personally don't see any issue with this. The binary is simply runtime
dependency, there is no need to have it present when building libvirt.
If someone is building any project from source code manually you can
consider these users advanced enough to figure all of this out or they
are following some tutorial where they most likely installed all
required build and runtime dependencies mentioned in the tutorial.
As Martin mentioned this would mostly affect only maintainers of
downstream libvirt packages where they have to have some understanding
of the project and it's dependencies in order to create the package
properly.
I feel like "some understanding" is an understatement considering the
sheer size of libvirt: it's entirely possible to have a pretty good
understanding of it and still get some of the details wrong.
In my opinion this move would place a significant burden upon
downstreams and users while taking very little burden away from
upstream developers because, regardless of whether or not build time
checks are performed, the task of maintaining the list of runtime
dependencies in *some* form still falls upon upstream: you would just
have changed it from updating three files to updating two.
--
Andrea Bolognani / Red Hat / Virtualization