Command not found -> automatic install proposes downgrades?

Ask Fedora
,
1

I tried to build a package using rpkg; on that machine, rpkg wasn’t installed yet though; this is what I got when I entered the command anyway:

$ rpkg
bash: rpkg: command not found...
Install package 'rpkg' to provide command 'rpkg'? [N/y] y


 * Waiting in queue... 
The following packages have to be installed:
 annobin-docs-11.06-2.fc37.noarch	Documentation and shell scripts for use with annobin
 annobin-plugin-gcc-11.06-2.fc37.x86_64	annobin gcc plugin
 ansible-srpm-macros-1-8.1.fc37.noarch	SRPM stage RPM packaging macros for Ansible collections
 debugedit-5.0-7.fc37.x86_64	Tools for debuginfo creation
 dwz-0.14-7.fc37.x86_64	DWARF optimization and duplicate removal tool
 efi-srpm-macros-5-6.fc37.noarch	Common SRPM Macros for building EFI-related packages
 fonts-srpm-macros-1:2.0.5-9.fc37.noarch	Source-stage rpm automation for fonts packages
 fpc-srpm-macros-1.3-6.fc37.noarch	RPM macros needed by packages built with Free Pascal Compiler
 gcc-plugin-annobin-12.2.1-4.fc37.x86_64	The annobin plugin for gcc, built by the installed version of gcc
 ghc-srpm-macros-1.6.1-1.fc37.noarch	RPM macros for building Haskell source packages
 gnat-srpm-macros-5-1.fc37.noarch	RPM macros needed when source packages that need GNAT are built
 go-srpm-macros-3.2.0-1.fc37.noarch	Source-stage rpm automation for Go packages
 http-parser-2.9.4-7.fc37.x86_64	HTTP request/response parser for C
 kernel-srpm-macros-1.0-15.fc37.noarch	RPM macros that list arches the full kernel is built on
 libgit2-1.3.2-1.fc37.x86_64	C implementation of the Git core methods as a library with a solid API
 libssh2-1.10.0-5.fc37.x86_64	A library implementing the SSH2 protocol
 llvm-15.0.7-1.fc37.x86_64	The Low Level Virtual Machine
 lua-srpm-macros-1-7.fc37.noarch	RPM macros for building Lua source packages
 nim-srpm-macros-3-7.fc37.noarch	RPM macros for building Nimble source packages
 ocaml-srpm-macros-7-2.fc37.noarch	OCaml architecture macros
 openblas-srpm-macros-2-12.fc37.noarch	OpenBLAS architecture macros
 package-notes-srpm-macros-0.5-6.fc37.noarch	Generate LDFLAGS to insert .note.package section
 perl-srpm-macros-1-46.fc37.noarch	RPM macros for building Perl source package from source repository
 preproc-0.5-6.fc37.noarch	Simple text preprocessor
 pyproject-srpm-macros-1.6.2-1.fc37.noarch	Minimal implementation of %pyproject_buildrequires
 python-srpm-macros-3.11-5.fc37.noarch	RPM macros for building Python source packages
 python3-cached_property-1.5.2-8.fc37.noarch	A cached-property for decorating methods in Python classes.
 python3-munch-2.5.0-10.fc37.noarch	A dot-accessible dictionary (a la JavaScript objects)
 qt5-srpm-macros-5.15.8-1.fc37.noarch	RPM macros for source Qt5 packages
 redhat-rpm-config-229-1.fc37.noarch	Red Hat specific rpm configuration files
 rpkg-3.2-3.fc37.noarch	RPM packaging utility
 rpkg-macros-2.0-3.fc36.noarch	Set of preproc macros for rpkg utility
 rpm-build-4.18.0-1.fc37.x86_64	Scripts and executable programs used to build packages
 rpm-git-tag-sort-1.0-8.fc37.x86_64	Sorts merged git annotated tags according to topology and rpm version sorting.
 rpmautospec-rpm-macros-0.3.5-1.fc37.noarch	Rpmautospec RPM macros for local rpmbuild
 rust-srpm-macros-24-1.fc37.noarch	RPM macros for building Rust projects
 systemd-rpm-macros-251.11-2.fc37.noarch	Macros that define paths and scriptlets related to systemd
The following packages have to be downgraded:
 cpp-12.2.1-4.fc37.x86_64	The C Preprocessor
 gcc-12.2.1-4.fc37.x86_64	Various compilers (C, C++, Objective-C, ...)
 gcc-c++-12.2.1-4.fc37.x86_64	C++ support for GCC
 gcc-gdb-plugin-12.2.1-4.fc37.x86_64	GCC plugin for GDB
 libgfortran-12.2.1-4.fc37.x86_64	Fortran runtime
 libgomp-12.2.1-4.fc37.x86_64	GCC OpenMP v4.5 shared support library
 libquadmath-12.2.1-4.fc37.x86_64	GCC __float128 shared support library
 libquadmath-devel-12.2.1-4.fc37.x86_64	GCC __float128 support
 libstdc++-12.2.1-4.fc37.x86_64	GNU Standard C++ Library
 libstdc++-devel-12.2.1-4.fc37.x86_64	Header files and libraries for C++ development
 llvm-libs-15.0.7-1.fc37.x86_64	LLVM shared libraries
 python3-rpm-4.18.0-1.fc37.x86_64	Python 3 bindings for apps which will manipulate RPM packages
 rpm-4.18.0-1.fc37.x86_64	The RPM package management system
 rpm-build-libs-4.18.0-1.fc37.x86_64	Libraries for building RPM packages
 rpm-libs-4.18.0-1.fc37.x86_64	Libraries for manipulating RPM packages
 rpm-plugin-selinux-4.18.0-1.fc37.x86_64	Rpm plugin for SELinux functionality
 rpm-plugin-systemd-inhibit-4.18.0-1.fc37.x86_64	Rpm plugin for systemd inhibit functionality
 rpm-sign-libs-4.18.0-1.fc37.x86_64	Libraries for signing RPM packages
 systemd-251.11-2.fc37.x86_64	System and Service Manager
 systemd-libs-251.11-2.fc37.x86_64	systemd libraries
 systemd-networkd-251.11-2.fc37.x86_64	System daemon that manages network configurations
 systemd-oomd-defaults-251.11-2.fc37.noarch	Configuration files for systemd-oomd
 systemd-pam-251.11-2.fc37.x86_64	systemd PAM module
 systemd-resolved-251.11-2.fc37.x86_64	Network Name Resolution manager
 systemd-udev-251.11-2.fc37.x86_64	Rule-based device node and kernel event manager
Proceed with changes? [N/y] n

I was astonished by the long list of packages under The following packages have to be downgraded, and aborted of course. Next thing I tried was to sudo dnf install rpkg, and lo and behold - no downgrades needed!
So why does the automatic installation propose those downgrades?

2

I believe that when a user selects to install package as you did the tool applied is packagekit.
Dnf and packagekit use the same repo source for packages, but the cached metadata on the machine is different so it can easily be out of sync in the two differing caches (and often is).

If packagekit metadata lags behind the dnf metadata and an update in the repo has occurred since packagekit last updated metadata then it can easily attempt to install older versions of packages.

I know of no way to force a metadata update with packagekit, though dnf has the --refresh option to force immediate metadata update when dnf is used.

Without the refresh option dnf has a 6 hour automatic metadata refresh cycle so it can also lag behind the data in the repos, though what you saw appears to be a simple variance in the refresh sync schedules for the 2 differing update tools.

1 Like
3

Thanks, I wasn’t aware of packagekit!

I’ve just been using dnf for installing software , as this was what was proposed on all pages I saw so far…
So basically there is no way for me as a user to resolve this other than just not using the automatic installation on command not found - right? Not my idea of good usability :slightly_frowning_face:
Or I would have to install all software via packagekit - how can I do that? Do GUI tools use that? I prefer command line though :grin:

4

The only time your method seems to be an issue is when there may be a sync issue with the metadata. I also use the cli and actually have never seen the type issue you noted, but I am aware of the potential issues that can occur. Usually the automatic install works properly.

5

What spin are you using?

Your PackageKit metadata cache appears to be at least 6 months out of date. I guess if you don’t have GNOME Software or KDE Discover refreshing it, there’s nothing else that would. It makes sense that PackageKit-command-not-found doesn’t refresh the cache; that would be infuriatingly slow, but it probably should just exit if the cache is expired.

You can manually refresh with pkcon refresh.

P.S. This issue should go away relatively soon as PackageKit is slated for replacement.

2 Likes
6

I think originally I installed workstation (i.e. gnome desktop), but switched to xfce and removed gnome, so that could be the issue.

Thanks for the hint!

7

Yeah, that’s probably why you have PackageKit-command-not-found installed in the first place. If I’m reading comps correctly, only Workstation and KDE install it by default.