On 2019-02-18, Ben Cotton <bcotton@xxxxxxxxxx> 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
