After installation, I looked at the output from dnf autoremove. To my surprise, it suggested 191 packages were to be removed - including ones that appear very fundamental to the functioning of the system (acl, initscripts, gettext, …). All of the packages are listed with a “.fc38” version as well - and when I checked I did not found more than one version of the same packaged installed either.
How can I fix this, so that this won’t cause problems at some later point? (I presume those packages aren’t safe to be removed?)
It’ll help to see the list of packages. Run the following command to upload it to the Fedora pastebin:
dnf -qC list --autoremove | fpaste
then reply with the URL.
Are you using Fedora Workstation or another edition/spin?
FWIW, initscripts is probably not used by most Fedora users (it’s for System V init scripts, while Fedora uses systemd), and gettext is needed for developing translations, not using them. acl should be installed though, it’s part of Workstation group.
I am tempted to suggest you run sudo dnf mark install \* that that should mark all packages as “user installed” and therefore autoremove won’t remove them. For any future installed packages autoremove would then work correctly.
I find that installing python3-dnf-plugin-show-leaves can be very useful, as it will show you which packages may no longer be needed when removing a package. You then have to decide which packages are really no longer required.
Does anyone know if Packagekit is now properly marking user installed packages as “user installed” and therefore not to be removed by autoremove?
I’m curious to see the transaction history of one of the packages that isn’t part of cloud or core/standard groups. Let’s say sound-theme-freedesktop, since it never receives updates, the only transactions should be whatever caused it to be installed, and the upgrade from F36 to F38:
dnf history info sound-theme-freedesktop | fpaste
Maybe you installed a package with all these desktop-related dependencies at one point. Not sure why they’d be leaves (orphans) now though.
Maybe it is a leaf, or maybe not. Perhaps it will become a leaf when some of the other packages are removed.
If you install python3-dnf-plugin-leaves-4.4.1-1.fc38.noarch and python3-dnf-plugin-show-leaves-4.4.1-1.fc38.noarch you can run the command dnf leaves
to get a list of leaf packages.
Whether a packages may be autoremoved depends on how it was installed. If it was installed like dnf install sound-theme-freedesktop, then it will not be autoremoved. If it was installed as a dependency, then it can be autoremoved.
Some package foo was installed at some point with all these desktop/GUI dependencies.
Either foo was removed, then why were the deps not autoremoved?
Or foo is still present, but the dependencies changed (almost absurdly) between F36 and F38?
sound-theme-freedesktop is just an example of one of these dependencies, I picked it because it’s very unlikely anyone installs it explicitly, and it has no updates. So maybe we can find out what foo is or what happened to it.
It is a server, and I never had X running on it. If I understand the output of dnf history right, then sound-theme-freedesktop was initially installed with ImageMagic. (Here is the pastebin.) That sounds about right… I did install it at some point, and it pulling in way too many dependencies sounds familiar. Perhaps a more recent package got rid of those dependencies? (I see imagemagic still installed at this point.)
So maybe that’s correct - but what about acl? Is there a way of figuring out what package/dependency I am missing that makes it (and possibly other essential ones) look ripe for autoremove?
ImageMagick was installed in F34, bringing in a bunch of dependencies (fonts, gtk3, sounds). Slightly heavy but seems normal.
During system-upgrade from F34 to F36, many more desktop dependencies were installed (video/audio stack, flatpak, some GNOME components, Bluetooth). Not sure why, but this is the root of the problem. Maybe it was something in the dependency chain of ImageMagick, maybe something else entirely.
system-upgrade from F36 to F38 seems normal. Whatever was the problem in F36 was fixed between F36 and F38, but system-upgrade doesn’t autoremove, so here we are.
Edit: removed instructions because they were based on wrong assumptions. See next post.
Oh I see now. standard group is an optional dep of Fedora Cloud Server group. My mistake assuming it’s a required group like on Workstation.
So, if you want acl, you can dnf mark install it before the autoremove, or install it yourself afterwards. Or, you can group install the standard group if you want everything else in it (it’s all CLI stuff, but more desktop-oriented).
To see the other optional groups in Cloud:
dnf group info 'Fedora Cloud Server'
You can install a group with all optional groups, but that’s probably not what you want here:
I ended up making a snapshot of the instance before trying to run autoremove (since it now looked like everything was in good order, and “acl” optional anyway). Unfortunately the instance did not come up after rebooting (no ping), so it seems like something wasn’t that optional…
I might go ahead and ultimately mark all packages as “user installed”, since I just don’t know which are safe to delete.