1:48 p.m.
On Fri, Nov 20, 2020 at 07:32:44PM +0100, Pavel Hrdina wrote:
On Fri, Nov 20, 2020 at 06:49:15PM +0100, Andrea Bolognani wrote:
> 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.
>
So let's assume the state of downstream packages is OK now and we are only
talking about added functionality from now on (technically it would also involve
new packaging systems and new distributions, but that's a corner case).
When we start using new binary than in your case we have to add a new dependency
in meson.build and libvirt.spec.in. If we go with my approach it consists of
updating only one file instead. Saying that updating something could be
error-prone is therefore a moo point because we are relying on that already and
the more so with the approach you are suggesting.
> In my opinion this move would place a significant burden upon
> downstreams and users while taking very little burden away from
Not really. As Olaf pointed out they need to rewrite more than just one check
because of licence implications. And there might be more. Also build-checking
libvirt requires way more packages to be installed even when you are just
building it.
If we ever forget to add the requirement into the specfile (or any other package
build descriptor file) then what will be the outcome? User will try to do
something and they get an error that binary "blah" is missing. They will
install "blah" and move on. Ideally they will report that to their distro
maintainer and they will be able to fix it right away. And since we are talking
about future features only that will most probably not happen on some automated
deployment because any such setup needs to be tested first.
I really do not see more problems with the approach I'm suggesting.
> 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.
I would say that nobody is arguing about the responsibility of providing
list of runtime dependencies. In fact IMHO the ideal solution would be
to have a complete list of all our dependencies with links to the
respective upstream projects to make it clear.
Having checks for runtime dependencies in our build system and use these
to figure out if the feature should be enabled or disabled is wrong and
should be removed completely and where needed replaced with different
checks for targeted OS, architecture, etc. It's not only about the
burden. The feature can be compiled without the presence of the binary
and the binary can be provided later. The same way it can be present
during the compilation but missing when libvirt is actually running.
For downstream maintainers having a list of dependencies is IMO way
better then running the build system several times to figure out what
else they need to add to the package dependencies in order to
successfully build the package. Obviously this applies to non-RPM based
distributions.
Like Martin already wrote, the current situation is already broken as
most of the runtime dependencies are optional and the build will not
fail if they are missing, so there is already a requirement for that
knowledge. Only if few cases the runtime dependency is used to
enable/disable some libvirt feature. And there are other runtime
dependencies that are not even mentioned in our build system.
Like I wrote, end-users compiling libvirt directly are usually following
some tutorial where the list of dependencies is already present and even
with the build time check they can still shoot themselves by removing
the runtime dependency once libvirt is compiled and/or installed so
there is no guarantee that it will solve all the scenarios for end
users.
The possibility to provide explicit absolute path to the runtime
dependencies is related but completely different issue. Again IMHO
I don't think that it's necessary to have these options.
Pavel