Bug 2249732 - dnf looking for outdated librpmio and librpm
Summary: dnf looking for outdated librpmio and librpm
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 39
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: amatej
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-11-15 03:05 UTC by Todd
Modified: 2023-12-05 05:53 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2023-12-05 05:53:33 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Todd 2023-11-15 03:05:19 UTC
Fedora 39
dnf-4.18.1-1.fc38.noarch

dnf is looking for outdated version 9 instead of version 10 of 
   librpmio
   librpm.so

# dnf whatprovides leafpad
Traceback (most recent call last):
  File "/usr/bin/dnf", line 61, in <module>
    from dnf.cli import main
  File "/usr/lib/python3.12/site-packages/dnf/__init__.py", line 30, in <module>
    import dnf.base
  File "/usr/lib/python3.12/site-packages/dnf/base.py", line 29, in <module>
    import libdnf.transaction
  File "/usr/lib64/python3.12/site-packages/libdnf/__init__.py", line 14, in <module>
    from . import conf
  File "/usr/lib64/python3.12/site-packages/libdnf/conf.py", line 10, in <module>
    from . import _conf
ImportError: librpm.so.9: cannot open shared object file: No such file or directory


Workaround:

   # cd /usr/lib64
   # ln -s librpmio.so.10.0.0 librpmio.so.9
   # ln -s librpm.so.10.0.0 librpm.so.9

Comment 1 Panu Matilainen 2023-11-15 07:41:55 UTC
> Fedora 39
         ^^
> dnf-4.18.1-1.fc38.noarch
                 ^^

You have dnf from Fedora 38 on claimed Fedora 39. Dnf itself is just a Python program and wont know anything about librpm versions, the underlying issue is some other package, presumably libdnf being similarly left at F38 version. And if there's one, there's likely to be more. You'll want to check 'rpm -qa|grep fc38' on that system.

I had something similar happen to me on my home desktop upgrade, but in my case rpm itself and the entire Python stack got held back, dnf didn't work and I had loads of "fun" manually resolving that with just rpm.

Comment 2 Todd 2023-11-15 10:56:33 UTC
Geez. I never tought to look at that.
    # dnf upgrade dnf  --releasever=39 --best --allowerasing
Screwed up a lot and left a lot of fc38 stuff in place

# dnf upgrade dnf  --releasever=39

Failed on its ....

# dnf upgrade   --releasever=39

3000+ file later,

# dnf upgrade dnf  --releasever=39 --best --allowerasing

273 files later, and

# rpm -qa dnf
dnf-4.18.1-1.fc39.noarch

# rpm -qa | grep -i fc38

And I still have hundred of rpm's on fc38. Using dnf whatprovides, I am finding that the fc38 versions are slightly higher than the fc39 versions:

# dnf whatprovides cups --releasever=39
Last metadata expiration check: 1:34:34 ago on Wed 15 Nov 2023 01:19:42 AM PST.
cups-1:2.4.7-1.fc39.x86_64 : CUPS printing system
Repo        : fedora
Matched from:
Provide    : cups = 1:2.4.7-1.fc39

cups-1:2.4.7-2.fc38.x86_64 : CUPS printing system
Repo        : @System
Matched from:
Provide    : cups = 1:2.4.7-2.fc38


GGGGRRRRRRR

Comment 3 Panu Matilainen 2023-11-22 07:55:32 UTC
You should use "distro-sync" instead of "upgrade" for distro upgrades, because despite packager best intentions, in the real world its not rare to have older packages in a newer distro due to updates getting out of sync.

Comment 4 amatej 2023-12-05 05:53:33 UTC
Another option would be to use the system-upgrade plugin which is designed for this: https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline/ (it does some additional things like upgrading groups and environments).

There doesn't appear to be a dnf bug so I am closing this.
If you find there is some dnf problem here after all please reopen.


Note You need to log in before you can comment on or make changes to this bug.