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).
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.
Installed Packages Name : libsolv Arch : x86_64 Version : 0.6.20 Release : 1.el7 Size : 671 k Repo : installed From repo : epel-testing Summary : Package dependency solver URL : https://github.com/openSUSE/libsolv License : BSD Description : A free package dependency solver using a satisfiability algorithm. The : library is based on two major, but independent, blocks: : : - Using a dictionary approach to store and retrieve package : and dependency information. : : - Using satisfiability, a well known and researched topic, for : resolving package dependencies.
Available Packages Name : libsolv Arch : i686 Version : 0.6.11 Release : 1.el7 Size : 308 k Repo : base/7/x86_64 Summary : Package dependency solver URL : https://github.com/openSUSE/libsolv License : BSD Description : A free package dependency solver using a satisfiability algorithm. The : library is based on two major, but independent, blocks: : : - Using a dictionary approach to store and retrieve package : and dependency information. : : - Using satisfiability, a well known and researched topic, for : resolving package dependencies.
On Sat, May 7, 2016 at 10:23 AM, Stephen John Smoogen smooge@gmail.com wrote:
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).
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.
As for now, the need for a newer libsolv implies that Red Hat needs to bump it up in the base, since they pulled it into there with RHEL 7.2.
On Sat, 7 May 2016 12:36:27 -0400 Neal Gompa ngompa13@gmail.com wrote:
On Sat, May 7, 2016 at 10:23 AM, Stephen John Smoogen smooge@gmail.com wrote:
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: http://pkgs.fedoraproject.org/cgit/rpms/libsolv.git/commit/?h=epel7&id=0...
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 to 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.
kevin
On 7 May 2016 at 14:11, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 7 May 2016 12:36:27 -0400 Neal Gompa ngompa13@gmail.com wrote:
On Sat, May 7, 2016 at 10:23 AM, Stephen John Smoogen smooge@gmail.com wrote:
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: http://pkgs.fedoraproject.org/cgit/rpms/libsolv.git/commit/?h=epel7&id=0...
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).
Ah ok that explains it. If you use dnf with the older libsolv it seems that it has problems with compression modes that CentOS and EPEL use for metadata. So the user who found the problem was not able to install or update packages with dnf without using the libsolv in epel-testing. weeeeee.
epel-devel@lists.fedoraproject.org
-
Kevin Fenzi -
Neal Gompa -
Stephen John Smoogen