F33 upgrade: transaction check fails because "rpmlib(CaretInVersions) <= 4.15.0-1 is needed"

Ask Fedora
1

When I run “dnf system-upgrade download --refresh --releasever=33” it fails with:

Running transaction check
Error: transaction check vs depsolve:
rpmlib(CaretInVersions) <= 4.15.0-1 is needed by python3-apsw-3.33.0.r1-1.fc33.x86_64
rpmlib(CaretInVersions) <= 4.15.0-1 is needed by python3-pip-20.2.2-1.fc33.noarch
rpmlib(CaretInVersions) <= 4.15.0-1 is needed by systemd-246.7-2.fc33.x86_64
rpmlib(CaretInVersions) <= 4.15.0-1 is needed by python-pip-wheel-20.2.2-1.fc33.noarch
To diagnose the problem, try running: 'rpm -Va --nofiles --nodigest'.
You probably have corrupted RPMDB, running 'rpm --rebuilddb' might fix the issue.
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.

How do I fix this? I tried using rpmfind.net to figure out what package I need but it’s coming up empty.

2

What release are you on currently, and is that up to date with the latest versions of everything?

3

I’m on 30, and it is up to date.

4

Try that first:

If the issue persists, follow this one:

1 Like
5

We officially test and support skipping one release, but skipping two or more will sometimes give you problems like this. I suggest going from 30 to 31 and then from there to 33.

2 Likes
6

I tried that. It didn’t do anything.

I solved the gpg problem. This isn’t that.

I know upgrading 3 versions at once isn’t officially supported, but this issue seems to be about the requirements of the F33 rpms and would happen even if I upgraded in steps.

7

This is likely requires a newer RPM version.
Upgrading to an earlier Fedora release should help due to lower dependency requirements.

8

I can’t guarantee that this will solve your problem, but this is definitely exactly the kind of situation that we can cover in steps: new RPM features can be backported to the previous still-supported release, but not to EOL ones. So in order to get to a version of RPM that can handle what the new packages need, you need to step forward.

9

You could possibly update just RPM and related packages, but that gets you into “oops, now I need to reinstall” territory dangerously quickly, so doing the release-by-release upgrade is the general recommendation. If you’re up for adventure, you could try to upgrade RPM first… but make sure you have backups just in case.

10

I actually tried installing the rpm packages that were downloaded for the upgrade, but they required installing the new glibc so I didn’t.

OK I guess I’ll fall back on upgrading to F32 and taking it from there.

I’m still puzzled by what exactly rpmlib(CaretInVersions) is, and what provides it. Googling doesn’t find anything other than the git diff where a check for it introduced into the codebase.

11

Yeah, exactly … that’s the adventure. :slight_smile:

In this case, the feature allows package versions to indicate snapshots using a notation where the snapshot date or version is after the package’s “real” released version number. So, if there’s a package at version 1.1, and the packager decides to patch it up to an unreleased version from December 24, 2020, they might use 1.1^20201224 as the package version. This will sort higher than 1.1, but lower than 1.1.1 or something.

This is mentioned in the changelog for RPM 4.14.3, but not actually helpfully described, so I hope the above makes it clear. :slight_smile:

I don’t know if any packages are actually using this, but I think maybe this concept comes from the Python world (see this), and python-pip-wheel is a package for dealing with Python packages, so it makes sense that that RPM feature would be required.

12

All that said, there’s definitely a bug here, because that is not at all a helpful error message.

13

I was able to upgrade to F32 without any rpm problems. The boot loader config is really messed up but that’s a whole other thread.

2 Likes