firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr) >= 4.16


For some reason I fail to understand, a non-devel package is
conflicting with a devel package :-/

According to dnf it's the only explicit conflict for the package:

$ dnf repoquery --conflicts firefox-55.0.2-2.fc26.x86_64
pkgconfig(nspr) >= 4.16

Maybe someone confused Conflicts with BuildConflicts in the spec?



Re: firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr)

By Martin Stransky at 08/30/2017 - 06:52

On 08/24/2017 04:46 PM, Dridi Boukelmoune wrote:
You're right, I confused the Conflicts with BuildConflicts (didn't
actually know that there's BuildConflicts). See
<a href="" title=""></a>


Re: firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr)

By Dridi Boukelmoune at 08/30/2017 - 09:15


On Wed, Aug 30, 2017 at 12:33 PM, Miroslav Suchý < ... at redhat dot com> wrote:
Non-optimal resolution is one problem, but not the reason why I
brought this to the devel list instead of filing a bug. But this is
interesting to know, thanks!

On Wed, Aug 30, 2017 at 12:52 PM, Martin Stransky < ... at redhat dot com> wrote:
OK, so this was not on purpose :)

The problem I had was that nspr-devel installed prevented an upgrade
of the nss package. Spurious blocking of nss updates is a red flag for
me, and I'm wondering whether the tooling could catch that sort of
things. Mainly, disapprove "normal" packages that conflict with devel
packages (or for that matter other kinds of special packages like

I don't think rpmlint would be a good candidate, because with a
virtual provide like pkgconfig(nspr) it's not obvious it will resolve
to a devel package (even though to my human eyes it's definitely
screaming devel). So maybe a check could be implemented with Taskotron
or something else, packages like golang libraries (source packages)
seem to be consistently suffixed with -devel, I can't tell for other

Are there guidelines covering that?


Re: firefox-55.0.2-2.fc26.x86_64 conflicts with pkgconfig(nspr)

By =?ISO-8859-2?Q?... at 08/30/2017 - 06:33

Dne 24.8.2017 v 16:46 Dridi Boukelmoune napsal(a):
Because there are several ways how to resolve the dependency and DNF chose from them one which is confusing for humans:
<a href="" title=""></a>