Bug 1463107 - Undoing a remove transaction marks packages as user installed
Summary: Undoing a remove transaction marks packages as user installed
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 25
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Eduard Čuba
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2017-06-20 07:07 UTC by Benjamin Xiao
Modified: 2017-08-09 18:41 UTC (History)
5 users (show)

Fixed In Version: dnf-2.6.3-1.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-09 16:00:13 UTC

Attachments (Terms of Use)

Description Benjamin Xiao 2017-06-20 07:07:34 UTC
Description of problem:
Undoing a remove transaction using `dnf history undo` seems to mark packages as user installed. This prevents autoremove from working properly later on.

Version-Release number of selected component (if applicable): 1.1.10

How reproducible:

Steps to Reproduce:
1. Install Blender via Gnome Software. Not sure if this step is necessary.
2. Remove blender via `dnf remove blender`. Note that autoremove works correctly right now and removes all dependencies.
3. `dnf history undo <transaction number of dnf remove blender>`
4. `dnf history remove blender` now only shows blender as the only package to be removed.

Actual results:
Step 4 shows blender as the only package marked for removal

Expected results:
Step 4 shows blender and all auto installed dependency packages marked for removal

Additional info:

Comment 1 Jaroslav Mracek 2017-06-21 11:42:49 UTC
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.

Comment 2 Benjamin Xiao 2017-06-22 22:18:25 UTC
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?

Comment 3 Jaroslav Mracek 2017-06-23 08:58:29 UTC
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.

Comment 4 Benjamin Xiao 2017-06-23 18:42:56 UTC
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?

Comment 5 Jaroslav Mracek 2017-06-23 19:45:58 UTC
It should also work.

Comment 6 Benjamin Xiao 2017-06-26 03:37:45 UTC
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

Comment 7 Benjamin Xiao 2017-06-26 03:51:38 UTC
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`.

Comment 8 Jaroslav Mracek 2017-07-21 07:36:29 UTC
Eda Cuda created a patch that should solve the issue (https://github.com/rpm-software-management/dnf/pull/864).

Comment 9 Jaroslav Mracek 2017-07-21 07:36:54 UTC
Eda Cuba created a patch that should solve the issue (https://github.com/rpm-software-management/dnf/pull/864).

Comment 10 Fedora Update System 2017-08-07 12:51:12 UTC
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

Comment 11 Fedora Update System 2017-08-08 01:24:45 UTC
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

Comment 12 Benjamin Xiao 2017-08-08 17:59:12 UTC
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.

Comment 13 Benjamin Xiao 2017-08-08 18:08:18 UTC
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?

Comment 14 Jaroslav Mracek 2017-08-09 07:48:37 UTC
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.

Comment 15 Eduard Čuba 2017-08-09 09:19:47 UTC
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:


Comment 16 Fedora Update System 2017-08-09 16:00:13 UTC
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.

Comment 17 Benjamin Xiao 2017-08-09 18:41:15 UTC
Thanks Jaroslav and Eduard for the fixes and detailed explaination!

Note You need to log in before you can comment on or make changes to this bug.