On Tue, Feb 19, 2019 at 4:26 PM Petr Pisar <ppisar@redhat.com> wrote:
On 2019-02-18, Ben Cotton <bcotton@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?

It should be general replacement for subpackage interdependencies with exact NEVRAs. Yes, it should (though I don't know how to implement it yet).
 
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-leave@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