Sudo dnf autoremove wants to remove qt?!

Ask Fedora
,
21

Hi, just to clarify some things here.

First about dnf, you can check all transactions that involved a particular package:

$ dnf history qt
$ dnf history info <transaction-id>

This will help you understand when/why a package was installed or modified.

About kate, AFAIK, it is not supposed to be part of the default KDE distribution in Fedora (kwrite is the included text editor). What seems to have happened is at the time of F37 release, the kwrite version was 22.08.2-1. kwrite depends on certain kate libraries, but at that point, the libraries were part of the kate package, so kate was pulled in as a dependency. This was fixed in kwrite-22.08.2-2 by creating a separate kate-libs package (rhbz#2137398 – RFE: Separate libkatepart.so from kate package).

If you installed the Fedora KDE spin, kde-desktop package group, or even just kwrite itself at F37 release, and subsequently updated it, you would have the kate package installed, but it is now a “leaf” package as 1) it was not explicitly installed by the user, and 2) no installed package depends on it. dnf autoremove will thus offer to remove it.

In my experience, most issues and confusion surrounding dnf autoremove are related to packaging changes like above (which are the result of upstream changes, or sometimes human error), and not a fault of the autoremove command itself.

Despite the “auto” in the name, it is very much a manual action that you should use carefully, as with any other dnf operation that changes your system. It automatically figures out what packages are leaves, but it cannot tell if you actually want a package or not. If you want to keep a leaf package, you have to mark it as userinstalled.

Yes, being on the “front lines” is one of the foundations of Fedora. It’s important for the ecosystem of free software that we have a widely-used distribution with leading edge software that is close to upstream. If every distro focused on stability (meaning slow to change, not bug-free), there would be few people testing new versions of upstream software—not just in isolation, but how they interact with other software, which is a never-ending task as every little change can have cascading effects.

Of course, it’s understandable if you want something more stable. There are downstream distros like CentOS Stream, RHEL, and EL clones that may better suit your needs.

That said, you don’t have to update Fedora every day. You can check for security updates and use your own judgement on when to update:

# dnf --security check-update

Note that third-party repos may not include this security information accurately or at all.

I check for security updates daily (automatically using a timer, which caches the update message that I then display in my terminal), but usually only do offline updates once a week using dnf offline-upgrade.

1 Like
22

I installed kate manually after installing Fedora 37 so it isn’t expected to be autoremoved.

I have dnf-automatic run online updates daily, and it rarely causes problems. What annoys me about offline updates is that I need to enter my LUKS password twice and wait quite some time for updates to complete.

Edit: I installed kate in this transaction:

dnf history info 4 | grep kate -i
Command Line   : install kate ... <lots of other packages>
    Install  libkate-0.4.1-25.fc37.x86_64                                   @fedora

I expected kate to be in the Install list.

After some time I noticed that kwrite still existed so I thought kate wasn’t installed:

dnf history info 7
<...>
Return-Code    : Success
Releasever     : 37
Command Line   : swap kwrite kate
Comment        : 
Packages Altered:
    Removed kwrite-22.12.0-1.fc37.x86_64 @@System

Nothing changed about kate in that transaction.

23

This yields the (rather unhelpful) result for me of:

ID     | Command line                                                                                | Date and time    | Action(s)      | Altered
--------------------------------------------------------------------------------------------------------------------------------------------------
     1 |                                                                                             | 2022-11-05 01:16 | Install        | 1900 EE

I guess that’s the time the F37 repo was officially signed off as released; I installed it around December 8th.

Good points re: the dogfood aspect, and the updating aspect. I did realize that and I’ve decided to stick with Fedora on this laptop regardless. However, I was sort of previewing Fedora as a prelude to installing it on a new 7950X desktop/development system, but I think I’m going to go with something else on that: I find the rate of updates is too great with Fedora, even if I ignore them for a week or more (I’ll be bothered knowing there are stacks of new bits piling up that I should install). I’m probably going to go back to Debian for that system, mainly for the LTS aspect, but it’s so far behind the curve that I really would like something that’s as up-to-date as F37 (like an LTS snapshot), but changes infrequently as Debian 11! Even Debian 12, when it becomes available in 6-9 months or so is going to have a ~5.15 kernel and ~10.x GCC. I already want Debian 13! (I’ve been running Debian 12/Bookworm alongside Debian 11 also.) I might be forced to go with Ubuntu LTS for that system but I’d really prefer an unchanging Fedora or an up-to-date Debian. RHEL might be what I want; I haven’t tried it.

Edit: a ~5.15 kernel on Debian 12 isn’t an issue - it likely runs fine on the new hardware out of the box, and I build the occasional kernel but ideally prefer not to change a distro myself if I can help it - it becomes a pain to manage the various versions, apt pinning, etc. That said, DIY kernels have been straightforward and problem-free thus far.

24

What likely happened is:

  • kate was already installed (probably in transaction 1, like Lionel’s case, due to the reasons I mentioned)
  • When you did dnf install kate ... in transaction 4, nothing happened with regard to kate because it was already installed. dnf install does not change the status of already installed packages like dnf mark would.
  • Subsequently, transaction 7 also did nothing w.r.t kate because it was already installed.

libkate is not related to the kate editor, it’s a coincidence it was installed in transaction 4. From dnf info libkate:

Kate is a karaoke and text codec meant for encapsulation in an Ogg container.

You can find out what you have installed that depends on it:

$ dnf rq --whatdepends libkate --installed
1 Like
25

Thanks for the insight! You’re right, libkate is used by the VLC player that’s why it got installed.

dnf rq --whatdepends libkate --installed
libtiger-0:0.3.4-24.fc37.x86_64
vlc-core-1:3.0.18-2.fc37.x86_64
26

You can use toolbox or distrobox with images of faster distros (like Fedora) to get newer gcc/libraries for development, while your host is a slower/LTS distro (be it Debian- or EL-based).

27

I’ve been running other distros - like Fedora - in VMs but it’s sub-optimal.

28

In my opinion, LTS is good in servers but not personal use.
About the frequency of updates: I don’t see it as a problem unless you have a metered connection. On my system dnf-automatic ran 7 upgrades in the last 19 days, not that much but of course this varies depending on your packages.

29

I don’t like rebooting. I am very critical of Windows requirement to frequently reboot on updates but honestly Fedora is worse, so far, which has been a bit of a shock. In my experience Debian virtually never requires a reboot.

My interest is mainly development. I want a stable system with an up-to-date toolchain (that I don’t have to chop and change distros to achieve). The latter is my biggest issue with Debian whereas the former is its biggest benefit IMO. That’s why I run other Linux distros in VMs (and Windows too), but I really want the one-distro-to-rule-them-all on the metal. Sadly, that mythical distro doesn’t seem to exist, at least not in my fairly limited experience (I have tried Debian, Fedora, Ubuntu and Manjaro; probably others too but I don’t remember. I’m not a distro-hopper: I just want to find one distro that works well for me: set and forget. So far that’s been Debian, except for the ancient compiler etc. I am not a big fan of K/Ubuntu - can’t really explain why (I prefer having a root account; that’s probably it) - but will probably end up running Kubuntu LTS. I already do run it on multi-boot Linux systems but it’s a very distant second place to Debian on my systems. I thought Fedora was going to be the new champion but I don’t think it’s going to meet my requirements on the desktop. I’ll keep it going on this laptop however.).

30

You don’t need to reboot for updates on Fedora, you can perform updates while the system is running normally. My recommendation:

  • Remove packagekit as for now it doesn’t play well with dnf: sudo dnf remove PackageKit && sudo systemctl stop packagekit
  • Install dnf-automatic and configure it to run updates automatically while the system is running:
    sudo dnf install dnf-automatic
    Set it up as you like, read the manpage for details.
    I have it set up to download and install all updates when available while the system is running, you can configure it to download security updates only.

Edit: A good compromise in your case is Kubuntu non-LTS, you need to upgrade every 6 months and otherwise it is as stable as Debian without the way too outdated packages.

Fedora is more of a leading edge and is also good for your use case. @icantremember

Every major distro can have that I think.

31

Thanks for the suggestion. I know I don’t have to update and reboot as often as Fedora/Discover would desire: I’m already putting off the latest (today’s) download & reboot.

I’ll give your recommendation a try.

Where can I find out what’s actually changing? I looked on bodhi.fedoraproject.org but didn’t find what I was looking for. E.g. this is the current list of binaries that are changing. Where can I find out why?

cf762ccbad31da9e3613bf60a5f56e3e21a3642f.png
cf762ccbad31da9e3613bf60a5f56e3e21a3642f.png1584×1398 359 KB

Thanks

32

Is this what you want?

If you want to keep discover working, then my previous suggestion isn’t for you (because packagekit is what makes discover work). Instead go to KDE settings, the last item is likely Software update, from there disable offline updates and set the update frequency you like.

33

I don’t recall ever seeing the option on Ubuntu. Maybe I just skipped past it in the installation procedure?

34

I don’t know, but it is as simple as running sudo passwd root and setting a password.

35

I did try dnf updateinfo first. It didn’t provide the granularity of info I was looking for.

36

sudo dnf repoquery --changelog <package-name> | less
How about that?

Also check your settings for offline updates as I mentioned earlier.

37

That gives a bit more info, thanks.

Maybe I install Kubuntu on the new desktop; maybe I just stick with Debian Bookworm (which has now been updated to a 6.1 kernel and is entering initial freeze status). I’ll be doing some installing and testing…

38

Containers have much lower overhead than VMs, and are arguably easier to use. toolbox/distrobox further integrate containers with the host by sharing the home folder, networking etc seamlessly.

They specifically solve your development use case:

To mix and match a stable base system (eg. Debian Stable, Ubuntu LTS, RedHat) with a bleeding-edge environment for development or gaming (eg. Arch, OpenSUSE Tumbleweed or Fedora with latest Mesa)

I recommend giving it a try, even on your Fedora host system. It’s useful for separating your dev packages from the host, being able to quickly change toolboxes to compile or test in different target distros or gcc/library versions.

dnf updateinfo --info shows advisories. These are usually quite detailed (at least for important packages).

dnf changelog --upgrades shows changelog entries for all packages with upgrades. These are the changelogs of the spec files used to make the packages, and aren’t meant to detail every change in the upstream software. For example it might just say “package xyz updated to 1.2.3” or “fixed bug #456” in reference to some packaging bug reported on rhbz.

If you want to dig further, you can search on Fedora Packages, follow the links to the package source, and look at the spec file and commit history.

If you mean what’s changing with the software from version to version, that’s up to upstream to provide within their software. Some do, some don’t; there’s no way to enforce it, no standard format. (Side rant: look at the mess in app stores like Apple/Google’s, where changelogs are mandatory to publish updates—most apps write nonsense, like a generic “We updated the app” for every update, or treat it as another social media / marketing channel.)