An interesting Fedora 29 DNF update loop with the createrepo package

June 12, 2019

For a while, my Fedora 29 home and work machines have been complaining during 'dnf update' with a very peculiar complaint:

# dnf update
Last metadata expiration check: 0:09:16 ago [...]
Dependencies resolved.

 Problem: cannot install both createrepo_c-0.11.1-1.fc29.x86_64 and createrepo_c-0.13.2-2.fc29.x86_64
  - cannot install the best update candidate for package createrepo_c-0.13.2-2.fc29.x86_64
  - cannot install the best update candidate for package createrepo-0.10.3-15.fc28.noarch
========= [....]
 Package        Architecture  Version        Repository  Size
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 createrepo_c   x86_64        0.11.1-1.fc29  fedora      59 k

(Using '--best --allowerasing' did not in fact force the upgrade.)

For a while I've been ignoring this or taking very light stabs at trying to fix it, but tonight I got irritated enough to finally do a full investigation. To start with, the initial situation is that I have both createrepo 0.10.3-15 and createrepo_c 0.13.2-2 installed. DNF is trying to upgrade createrepo to createrepo_c 0.11.1-1, but this is naturally conflicting with the more recent version of createrepo_c that I already have installed.

I don't know quite how I got into the underlying situation, but I believe that interested parties can reproduce it on a current Fedora 29 system (and possibly on a Fedora 30 one as well) by first installing mock, which pulls in createrepo_c 0.13.2-2, and then the older and now apparently obsolete mach, which will pull in createrepo. At this point, a 'dnf update' will likely produce what you see here. To get out of the situation, you must DNF remove mach and createrepo (conveniently, 'dnf remove createrepo' will ripple through to remove mach as well).

To start understanding the situation, let's do an additional DNF command:

# dnf provides createrepo
createrepo-0.10.3-15.fc28.noarch : Creates a common metadata repository
Provide    : createrepo = 0.10.3-15.fc28

createrepo_c-0.11.1-1.fc29.x86_64 : Creates a common metadata repository
Provide    : createrepo = 0.11.1-1.fc29

In the beginning, there was createrepo, written in Python, and it was used by various programs and packages that wanted to create local RPM repositories, including both Mach and Mock. As a result of this, the Fedora packages for various things explicitly required 'createrepo'. Eventually the RPM people decided that they needed a version of createrepo written in C, so they created createrepo_c. In Fedora 29, Fedora appears to have switched which createrepo implementation they used to the C version. Likely to ease the transition, they made the initial version or versions of their createrepo_c RPM also pretend that it was createrepo, by explicitly doing an RPM provides of that name. This made createrepo_c 0.11.1-1 both a substitute for the createrepo RPM and an upgrade candidate for it, since it has a more recent version (this is the surprise of 'Provides' in RPM).

(The RPM changelog says this was introduced in 0.10.0-20, for which the only change is 'Obsolete and provide createrepo'.)

Over time, most RPMs were updated to require createrepo_c instead of createrepo, including the mock RPM. However, the mach RPM was not updated, probably because Mach itself is neglected and likely considered obsolete or abandoned. Then at some point the the Fedora people stopped having their createrepo_c RPM fill in for createrepo this way. Based on the RPM changelog for createrepo_c, this happened in 0.13.2-1, which includes a cryptic changelog line of:

  • Do not obsolete createrepo on Fedora < 31

Presumably the Fedora people have their reasons, and if I wanted to trawl the Fedora Bugzilla I might even find them. However, the effect of this change is that older createrepo_c RPMs in Fedora 29 are updates for createrepo but newer ones aren't.

So, if you 'dnf install mock', you will get mock and the current version of createrepo_c, which doesn't provide createrepo. If you then 'dnf install mach', it requires createrepo and the best version it can actually install is the actual createrepo 0.10.3-15 RPM that was built on Fedora 28. However, once that is installed, DNF will see the 0.11.1-1 version of createrepo_c from the Fedora 29 release package set as an update candidate for it, but that can't be installed because you already have a more recent version of createrepo_c.

(I suspect that if you install mach first and mock second, you will get only createrepo_c but will be unable to upgrade it past 0.11.1-1 without erasing mach.)

Written on 12 June 2019.
« Keeping your past checklists doesn't help unless you can find them again
My weird problem with the Fedora 29 version of Firefox 67 »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Jun 12 00:51:43 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.