On 2019-02-18, Ben Cotton <bcot...@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
