On 2019-02-18, Ben Cotton <bcotton(a)redhat.com> wrote:
Let's take graphene as an example.
Spec file contains:
<pre>
%package devel
Requires: %{name}%{?_isa} = %{version}-%{release}
%package tests
Requires: %{name}%{?_isa} = %{version}-%{release}
</pre>
What we see when we build RPMs is:
* <code>graphene-devel</code> requires <code>graphene(x86-64) =
1.8.2-3.fc30</code> AND <code>libgraphene-1.0.so.0()(64bit)</code> AND
<code>pkgconfig(graphene-1.0)</code>
* <code>graphene-tests</code> requires <code>graphene(x86-64) =
1.8.2-3.fc30</code> AND <code>libgraphene-1.0.so.0()(64bit)</code>
What can we do?
* <code>Requires: libgraphene-1.0.so.0()(64bit)</code> is actually
provided by <code>graphene</code> (coming from same package), so it
can be dropped in favor of <code>Requires: graphene(x86-64) =
1.8.2-3.fc30</code>
* <code>Requires: pkgconfig(graphene-1.0)</code> is provided by
<code>graphene-devel</code> (coming from the same subpackage), so it
can be dropped entirely
Is this feature resticted to the dynamic library soname dependencies, or
will it be a general replacement for subpackage interdependencies with
exact NEVRAs? Will this feature also apply to boolean dependencies?
I have a few packages that use "virtual provides" provided by multiple
subpackages to allow users to select an implementation that best fits
his needs. See perl-Archive-Extract for an example.
How would you cope with this use case?
-- Petr