On Sat, 7 May 2016 12:36:27 -0400
Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, May 7, 2016 at 10:23 AM, Stephen John Smoogen
> So I had someone come in on the EPEL list today asking why dnf in
> EPEL wasn't working. The problem is that dnf relies on a libsolv
> which is newer than the one that is provided by the base OS. This
> means that we can't approve libsolv in epel-testing (and should not
> have approved dnf to go into EPEL proper either).
So, here's what happened.
libsolv was not in rhel, it was added to epel7.
Then it was added to rhel, so it was marked dead in epel7, however, it
wasn't properly blocked in koji at the time:
Then, the maintainer forgot it was in rhel and merged in the master
branch and built it (which would have been blocked by it being blocked
in koji, but it wasn't).
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1334056
to track this.
> I am going to bring this up with the EPEL steering committee and
> see if we can come up with a process to let this in somehow. I also
> need to make sure we have better tooling in place so we aren't
> allowing stuff which replaces base packages.
RHEL 7 didn't originally have libsolv in the base, which is probably
why it was in EPEL. DNF (and libsolv) was pushed into EPEL so that
newer versions of mock would work correctly, which is required for the
Fedora Koji instance to build Fedora releases.
That is incorrect as far as I know. It's only in there as a
preview/testing for people who want to use it. Fedora koji (via mock)
correctly uses yum for epel releases, not dnf.
As for now, the need for a newer libsolv implies that Red Hat needs
bump it up in the base, since they pulled it into there with RHEL 7.2.
Sure, or the dnf update removed that needs this newer libsolv for now.