Not all unused dependences are offered to be removed on uninstall

[birdie-github]

Test case:

dnf install qterminal
Installing:
 qterminal            x86_64             2.0.1-1.fc41
Installing dependencies:
 layer-shell-qt       x86_64             6.2.2-2.fc41
 qt6-qtwayland        x86_64             6.8.0-2.fc41
 qtermwidget          x86_64             2.0.1-1.fc41

Now let's uninstall it:

dnf remove qterminal
Removing:
 qterminal           x86_64             2.0.1-1.fc41
Removing unused dependencies:
 layer-shell-qt      x86_64             6.2.2-2.fc41
 qtermwidget         x86_64             2.0.1-1.fc41

Transaction Summary:
 Removing:           3 packages

Maybe it was just like that with dnf but I'm not sure.

Using dnf5 in fully updated Fedora 41.

[m-blaha]

Were those two dnf commands run back-to-back, or was there any other dnf activity in between?

Some packages may not have been removed because they are direct or indirect dependencies of a protected package. So for example in this scenario:

# dnf install qterminal
# dnf install plasma-desktop
# dnf remove qterminal

The qt6-qtwayland package would not be removed, because it would cause removal of the protected plasma-desktop package - plasma-desktop requires qt6-qtwayland.
If this is the case, you should be able to observe something similar to this:

# dnf remove qt6-qtwayland
Failed to resolve the transaction:
Problem: installed package plasma-desktop-6.2.2-2.fc41.x86_64 requires libQt6WaylandClient.so.6()(64bit), but none of the providers can be installed
  - installed package plasma-desktop-6.2.2-2.fc41.x86_64 requires libQt6WaylandClient.so.6(Qt_6)(64bit), but none of the providers can be installed
  - conflicting requests
  - problem with installed package

(the reporting here could have been better and clearly say Problem: The operation would result in removing the following protected packages: plasma-desktop)

[birdie-github]

1. Those commands were indeed run back to back.
2. Nothing on the system depends on qt6-qtwayland. I don't have KDE installed.

[m-blaha]

That's strange. Would you mind sharing solver debugging data for the removal operation?

# dnf remove qterminal --debugsolver

This should create in the working directory quite a large debugdata directory. It contains simplified repository metadata for all used repositories (in this case there should be only the system repo with installed packages) and then libsolv's test case describing the job and the result. The directory is created right after solving the transaction, so you don't need to confirm it and actually proceed with removal.
Please make sure, that the dnf remove actually reproduces the issue (qt6-qtwayland package is missing in the transaction table).
If you don't mind, archive the debugdata directory and share it with me - my e-mail is [email protected]

[birdie-github]

I've emailed the debug log.

[m-blaha]

Thank you, your debug data were very helpful. Here is a minimal reproducer for your issue in libsolv testcase format:

repo @System 0 testtags <inline>
#>=Pkg: qt6-qtbase-gui 6.8.0 4.fc41 x86_64
#>=Rec: qt6-qtwayland(x86-64)
#>
#>=Pkg: qterminal 2.0.1 1.fc41 x86_64
#>=Req: libQt6WaylandClient.so.6()(64bit)
#>
#>=Pkg: qt6-qtwayland 6.8.0 2.fc41 x86_64
#>=Prv: qt6-qtwayland(x86-64) = 6.8.0-2.fc41
#>=Prv: libQt6WaylandClient.so.6()(64bit)

system x86_64 rpm @System

solverflags allowdowngrade allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans yumobsoletes focusnew

job erase pkg qterminal-2.0.1-1.fc41.x86_64@@System [cleandeps]
job allowuninstall pkg qt6-qtwayland-6.8.0-2.fc41.x86_64@@System

result transaction,problems <inline>
#>erase qterminal-2.0.1-1.fc41.x86_64@@System
#>erase qt6-qtwayland-6.8.0-2.fc41.x86_64@@System

(The last line erase qt6-qtwayland-6.8.0-2.fc41.x86_64@@System isn’t actually in the libsolv result; it’s included to show your expectation that this package would be removed alongside qterminal.)

Let me translate it to English.

Let's have a system with three packages installed:

1. qt6-qtbase-gui which recommends qt6-qtwayland (this package was installed prior to executing dnf install qterminal and was installed without weak dependencies, so qt6-qtwayland was not pulled in)
2. qterminal which requires qt6-qtwayland using one of its provides
3. qt6-qtwayland which was installed as a dependency of qterminal

Now, attempting to remove qterminal along with unused dependencies won't remove the qt6-qtwayland dependency, as it's still recommended by the installed qt6-qtbase-gui package.

I believe the dnf behavior here is correct. You can either remove qt6-qtwayland, or remove qt6-qtbase-gui package which keeps qt6-qtwayland installed.

I propose closing this issue as "not a bug".

[birdie-github]

as it's still recommended by the installed qt6-qtbase-gui package.

Exactly what I thought.

I'm not a fan of saying that's all working as intended. Logically your reasoning seems off.

Previously installed packages didn't have this package installed as an optional/recommended dependency, meaning the user consciously chose not to have it.

Now RPM/DNF/libsolve decide for the user that this recommended package is still needed due to a weak dependency against some other previously installed packages on the system.

Either way, you have the final say. If you think that's all fine, so be it.

[m-blaha]

Although I admit that you are right, the implementation will be challenging and would require changes in the libsolv first. Feel free to open an issue there as well, and you can use the provided testcase.

To fully address the issue, dnf would need to retain information about whether each package was installed with or without weak dependencies and then inform libsolv so that the recommends from packages installed without weak dependencies don’t block removal.
Hmm, even that might not fully address it—as some weak dependencies could have been excluded during the installation, meaning the package was only installed with a subset of its weak dependencies. So, to fully support this use case, we’d likely need to keep a complete list of weak dependencies that were installed with each package. And then there’s the additional complexity of backward weak dependencies, like Supplements...

I can keep this open with low priority, but honestly, I don’t think the benefits of this change would justify the resources required to implement it.

[birdie-github]

Thanks.

I guess you may as well never implement this feature and leave this bug report open, so that people could find it and realize what's going on.

[kontura]

This is an interesting issue, to me it looks like the other side of exclude_from_weak_autodetect config option.

Based on that I think libsolv already could have the needed syntax to support that: SOLVER_EXCLUDEFROMWEAK.

Unfortunately it doesn't seem to work, adding job excludefromweak name qt6-qtwayland to the mentioned testcase still fails to remove the package.

[m-blaha]

For now, I'm thinking about documenting the current behavior in dnf-remove(8) and dnf.conf(5), section clean_requirements_on_remove.