Hello, On Wed, Aug 30, 2017 at 12:33 PM, Miroslav Suchý <msuchy@xxxxxxxxxx> wrote: <snip> > Because there are several ways how to resolve the dependency and DNF chose > from them one which is confusing for humans: > See > https://bugzilla.redhat.com/show_bug.cgi?id=1485881 > Already 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 <stransky@xxxxxxxxxx> wrote: > On 08/24/2017 04:46 PM, Dridi Boukelmoune wrote: <snip> >> Maybe someone confused Conflicts with BuildConflicts in the spec? > > > You're right, I confused the Conflicts with BuildConflicts (didn't actually > know that there's BuildConflicts). See > https://bugzilla.redhat.com/show_bug.cgi?id=1484345#c11 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 debuginfo). 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 stacks. Are there guidelines covering that? Dridi _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
