On the festival of installation and rebooting that is Fedora 37 I thought I’d do a little distro health maintenance after today’s reboot (it’s a daily occurrence of late) and dnf wants to remove qt!?! On a KDE system?!?! What? Anyone care to theorize what’s up here?
Dependencies resolved.
=====================================================================================================================================================
Package Architecture Version Repository Size
=====================================================================================================================================================
Removing:
dbusmenu-qt x86_64 0.9.3-0.29.20160218.fc37 @anaconda 205 k
gtk2-immodule-xim x86_64 2.24.33-10.fc37 @anaconda 40 k
gtk3-immodule-xim x86_64 3.24.36-1.fc37 @updates 40 k
ibus-gtk4 x86_64 1.5.27-4.fc37 @updates 44 k
ibus-qt x86_64 1.3.4-3.fc37 @anaconda 442 k
kate x86_64 22.12.1-1.fc37 @updates 17 M
kate-plugins x86_64 22.12.1-1.fc37 @updates 11 M
qt x86_64 1:4.8.7-69.fc37 @anaconda 18 M
qt-at-spi x86_64 0.3.1-24.fc37 @anaconda 347 k
qt-common noarch 1:4.8.7-69.fc37 @anaconda 0
qt-x11 x86_64 1:4.8.7-69.fc37 @anaconda 37 M
sni-qt x86_64 0.2.7-0.11.20170217.fc37 @anaconda 142 k
Transaction Summary
=====================================================================================================================================================
Remove 12 Packages
Freed space: 84 M
Is this ok [Y/n]:
And is anyone else seeing this or anything like it? I think I’d better change the default dnf response back to 'No" before my reboot issues are solved (but not in a good way).
Those could be old packages that need to be removed. Try ‘which qt’ and ‘dnf info qt’, this may bring a lot of info, but it should tell you what is the current version. Then compare the release numbers.
“which qt” doesn’t find anything with that name on the path (and my earlier attempt at a global find didn’t yield anything just called qt).
dnf info qt returns slightly different info: different repos, same version. But I still don’t get the impression that autoremoving qt would be a good idea! I’m sure I’ll end up in a Linus-like situation (that’s the Linus Tech Tips Linus who ended up nuking his Pop! OS installation when removing Steam bits, not the real one!)
Oh, the “available” qt is for i686. Why is it showing availability for a 32-bit platform?
Fedora 37 - x86_64 30 kB/s | 22 kB 00:00
Fedora Modular 37 - x86_64 191 kB/s | 21 kB 00:00
Fedora 37 - x86_64 - Updates 54 kB/s | 21 kB 00:00
Fedora 37 - x86_64 - Updates 6.2 MB/s | 7.5 MB 00:01
Fedora Modular 37 - x86_64 - Updates 201 kB/s | 23 kB 00:00
google-chrome 8.4 kB/s | 1.3 kB 00:00
google-chrome 12 kB/s | 3.6 kB 00:00
google-chrome-unstable 11 kB/s | 1.3 kB 00:00
google-chrome-unstable 13 kB/s | 3.6 kB 00:00
RPM Fusion for Fedora 37 - Free - Updates 4.1 kB/s | 3.2 kB 00:00
RPM Fusion for Fedora 37 - Free - Updates 448 kB/s | 310 kB 00:00
RPM Fusion for Fedora 37 - Nonfree - Updates 10 kB/s | 3.7 kB 00:00
RPM Fusion for Fedora 37 - Nonfree - Updates 74 kB/s | 65 kB 00:00
Installed Packages
Name : qt
Epoch : 1
Version : 4.8.7
Release : 69.fc37
Architecture : x86_64
Size : 18 M
Source : qt-4.8.7-69.fc37.src.rpm
Repository : @System
From repo : anaconda
Summary : Qt toolkit
URL : http://qt-project.org/
License : (LGPLv2 with exceptions or GPLv3 with exceptions) and ASL 2.0 and BSD and FTL and MIT
Description : Qt is a software toolkit for developing applications.
:
: This package contains base tools, like string, xml, and network
: handling.
Available Packages
Name : qt
Epoch : 1
Version : 4.8.7
Release : 69.fc37
Architecture : i686
Size : 5.0 M
Source : qt-4.8.7-69.fc37.src.rpm
Repository : fedora
Summary : Qt toolkit
URL : http://qt-project.org/
License : (LGPLv2 with exceptions or GPLv3 with exceptions) and ASL 2.0 and BSD and FTL and MIT
Description : Qt is a software toolkit for developing applications.
:
: This package contains base tools, like string, xml, and network
: handling.
I wondered the same: it’s not really a very offensive editor…
I think that I’ll refrain from removing qt, even in the interests of science. I’d rather not risk a system without a desktop environment or worse. I have other systems I could experiment on.
It doesn’t hurt to keep it, but also it doesn’t seem to affect the system. The desktop package is plasma-desktop and that isn’t being autoremoved so you should be safe. At the very worst you could login from tty3 and run sudo dnf history undo -1.
‘autoremove’ is careful about removing vital system packages. There are times when there maybe be an older version of a package still on the system. When I mention ‘which qt’ it may not be exactly named ‘qt’. It could be qt4 or qt5 or something.
You have:
Installed Packages
Name : qt
Epoch : 1
Version : 4.8.7
Release : 69.fc37
Architecture : x86_64
Also notice in the screenshot you posted the ‘qt’ shown is saying there is an i686 version available.
That does not mean it will install it. It’s just available. Some systems still run as 32bit platforms.
On systems using apt-get or apt, it shows whether the package is installed or not. There may be something similar using ‘dnf’
That’s showing that it’s thinking of removing Qt 4, but current KDE is based on Qt 5. You also wouldn’t be able to remove a Qt that is being used by Plasma without also removing Plasma. Since that wasn’t being suggested, this Qt is not relevant for your desktop environment. If you want to stop autoremove from suggesting kate, you can mark it as user installed:
Did you try and to run it first? Before reinstalling it? It may have only removed the previous version, and the current version was in fact still on your system.
The dnf autoremove does not work like the dnf remove option. It will only remove orphaned packages. Packages that are no longer needed.
I think you may have found a bug indeed. Autoremove only removes orphan’s. Could be something went wrong in the packaging. Some flag didn’t get set during compiling.
dnf autoremove does not seem to work reliably. Users are reporting problems since a long time, see Search results for 'autoremove' - Fedora Discussion (and even the previous forum had a lot of questions reqgarding autoremove). Yes, it may not be dnf’s fault, but who has to the time to mark install <important packages>?
the best is not to use it, unless you understand the consequences of removing the suggested packages and you absolutely need those 84 MB. In my opinion, the risk of breaking the system or removing packages that you want to keep (like kate) is too high compared to what you gain (a few MB disk space)
It’s funny, today we are talking about how insignificant 84MB is. My first computer was a Tandy 2500 SX from Radio Shack. One of its marketing points was it had a whopping 85MB hard drive. I was the envy of the community.
I would not think those packages are anything other than a holdover from previous versions that were not removed during upgrades. They should not cause any problems if you remove them.
The current fedora releases seem to use only qt5 & qt6. Notice that the autoremove that you listed did not include the qt-settings package which was installed by anaconda for me.
It may also be of note that I upgraded my system from 36 to 37.
I later ran dnf check and it showed over 3000 packages as duplicates, all with the same fc37 version, but all with one entry from @System and one entry from @fedora. I ran dnf remove --duplicates and the anomaly was cleared up by downloading and reinstalling every package in that list from ‘dnf check’.
This is a new laptop with Fedora 37 installed (by me). There haven’t been any previous versions.
My understanding is that qt5 is the current version and qt6 is what the next major release of KDE will be based on. I noticed there was no qualifying number, in fact nothing other than “qt”, but still, after hearing about Linus (Tech Tips)’ bad experience with removing suggested packages and losing his entire DE I decided I can live with an unreclaimed 84MB rather than take the risk. If this was a VM then sure, I’d give it a whirl, but it’s my main laptop and I’d rather not do a full reinstall for the SIXTH time (previous lot were trying to get the correct Nvidia solution installed (based on random websites rather than this forum it must be admitted)).
Doing the autoremove should have a greater than 0.5 probability of success, but given the above questionable experience others had with kate it was suggested for removal for me too - I think I’ll choose the more conservative option. 84MB represents a lot of binaries and libraries, and given that as I say, this system has only had Fedora 37 on it, I don’t really trust that I’m not going to experience some problem that results in a broken system. I generally live by the old engineering maxim: if it ain’t broke, don’t fix it.
PS: Good lord: I just looked and there’s another 18 packages to update. Honestly, running Fedora feels like being on the front lines of operating system development and having to dogfood the latest bits every day. On the plus side, I haven’t experienced a regression - that I’ve recognized! - yet. Is this normal, or is just a particularly busy time for updates? I think I’ve been spoiled by only running LTS releases previously!
I recommend that you have a snapshot system. If you have ext4 root then use timeshift, or snapper if you have btrfs root. I keep 1 week worth of daily snapshots with btrfs so a mess could be easily dealt with. Thats why I casually ran the autoremove, knowing that at worst I can roll back yesterday’s snapshot.
Thanks, that’s a good suggestion. I haven’t done that on any Linux distro (outside of a VM) since I’ve never had an issue with having to return to a previous time point, although it may have saved me all those re-installs trying to get Nvidia drivers working!
