Bug 1463107

Please can you try the issue with dnf-2.5 available from our test repository (dnf copr enable rpmsoftwaremanagement/dnf-nightly)? We fixed there a lot of issues including inheritance of package's reason.

Hi Jaroslav, when i add that repo and do an update, it wants to remove anaconda and a few related packages. Not sure if I should do this or not. What's the proper way to upgrade to DNF 2.5?

Hi Benjamin,
Anaconda is a system installer that is not needed by 99% of users. It is only needed if you want to build your own disk image for installing. DNF-2.5 is designed for fedora26+ where there is any compatibility issue. 

Other known compatibility issues in Fedora25 with dnf-2.5+:
 - yumex-dnf will not work properly (downgrade to dnf-1.1* will restore functionality)

Also dnf-plugins will be upgraded to version 2.X.

I can promise that after test you can easily downgrade to dnf-1.1*.  
Only you have to check if all plugins will be correctly downgraded. 

Unfortunately without your help we cannot solve the issue. Please can you test it with dnf-2.5, because I was unable to reproduce it with dnf-2.5.1_1-8g38ad7bd.fc25.noarch, libdnf-0.9.1-1.fc25.x86_64?

Thanks a lot.

Sure thing Jaroslav, I was just afraid there wasn't an easy downgrade path. I can use dnf history undo to downgrade to dnf 1.1?

It should also work.

Hi Jaroslav, I actually just upgraded to Fedora 26, running DNF 2.5.1

I used the steps to reproduce listed above and was able to successfully reproduce the issue. Step 4 doesn't remove the packages installed to fulfill Blender's dependencies. I think its definitely due to the way Step 3 reinstalls the packages that were removed in Step 2

I double checked the yumdb reason for all the packages installed in Step 3 and they all say `history`. The original install reason is no longer kept and that's why `dnf remove blender` in step 4 fails to work.

I also want to amend my steps to reproduce.

Step 1: Installing via Gnome Software is not necessary. Installing blender via "dnf install blender" is sufficient. We can safely exclude Gnome Software and PackageKit from root cause.

Step 4: It should read `dnf remove blender` not `dnf history remove blender`.

Eda Cuda created a patch that should solve the issue (https://github.com/rpm-software-management/dnf/pull/864).

Eda Cuba created a patch that should solve the issue (https://github.com/rpm-software-management/dnf/pull/864).

dnf-2.6.3-1.fc26 dnf-plugins-extras-2.0.2-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4813633f96

dnf-2.6.3-1.fc26, dnf-plugins-extras-2.0.2-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4813633f96

Seems to work with the test update!

Two minor issues though.

1. "dnf install blender" installs a total of 53 packages, including google-droid-sans-fonts. "dnf remove blender" removes a total of 52 packages and leaves google-droid-sans-fonts installed. Why is it not properly removing the package.

2. dnf remove blender seems to miscount the number of packages it wants to remove. It only counts 40, when it is removing 52 packages. It doesn't count the packages in the "Removing depended packages:" section.

Uh oh, actually just tested with PackageKit using my original set of instructions (install Blender via PackageKit in first step) and I can still reproduce the error.

1. Install Blender via Gnome Software.
2. Remove blender via `dnf remove blender`.
3. `dnf history undo <transaction number of dnf remove blender>`
4. `dnf remove blender` now only shows blender as the only package to be removed.

Does a fix need to be applied for PackageKit as well since it doesn't use the same DB?

For Comment 12:
#1 - The difference is because dnf removes safely unused dependencies. It usually happen when dependency provide something that is required by other package, but it is also redundantly provided by other package. This is because some packages provide some services only virtually (packager mistake) and removal of redundant provides could result in broken system.

#2 - I create a patch (https://github.com/rpm-software-management/dnf/pull/890) that should fix the issue.

Thanks a lot for your comments.

For comment #13

PackageKit unfortunately only logs its transactions into yumdb - which doesn't hold the history of transactions like the historydb.

"dnf history undo last" looks at the reason from the last transaction before transaction being undone in historydb - which ich unavailable in case of installation using PackageKit. 

The problem of better integration of DNF and PackageKit is being addressed by Unified Software database for DNF and PackageKit project. This should fix the issue:

https://github.com/rpm-software-management/libdnf/pull/199
https://github.com/rpm-software-management/dnf/pull/785

dnf-2.6.3-1.fc26, dnf-plugins-extras-2.0.2-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Thanks Jaroslav and Eduard for the fixes and detailed explaination!