Bug 1276897 - DNF/YUM - Longstanding Dispay Bug
DNF/YUM - Longstanding Dispay Bug
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
25
All Linux
low Severity unspecified
: ---
: ---
Assigned To: rpm-software-management
Fedora Extras Quality Assurance
: Triaged, UserExperience
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-31 21:04 EDT by John C. Beima
Modified: 2017-04-18 11:19 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-18 11:19:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Photo displaying output. (249.82 KB, image/png)
2015-10-31 21:04 EDT, John C. Beima
no flags Details

  None (edit)
Description John C. Beima 2015-10-31 21:04:07 EDT
Created attachment 1088294 [details]
Photo displaying output.

Description of problem:

When you use DNF or YUM to erase 2 kernels, the progress/status section of the output in the "erasing" block says it is "erasing" the first kernel more than once and does not mention the second kernel.

The "verification" section displays properly.

Please see the attached image.


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

All versions, for a very long time have done this.


How reproducible:

Simply erase 2 out of the 3 installed kernels.

Steps to Reproduce:
1. dnf erse kernel-core-1 kernel-core-2
2. "Y"
3. Look at the status Section.

Actual results:

DNF appears to remove the kernels properly. This appears to just be a cosmetic "status" bug in the "erasing" section.


Expected results:

Things work as expected.


Additional info:
Comment 1 Honza Silhan 2015-11-02 10:42:16 EST
What version of DNF are you using? I remember we were fixing something like that.
Comment 2 John C. Beima 2015-11-02 11:30:58 EST
I believe teh machine I captured this from is 1.1.3-1, however it has been in all versions of dnf that shipped with Fedora 22.

I also believe this has been in yum for years before this.

I do recall the verification section used to do it as well, but I believe it was fixed at some point. Which appeared strange that only one section was fixed.

I would guess that dnf's status section is not really setup to handle more than one packing with the same name, since the kernel is the only time it happens.

Possibly searching the list of packages to process from the begining everytime instead of from where it is at?

Just a theory.
Comment 3 John C. Beima 2015-11-02 11:32:24 EST
ONe additional note.

This does happen each and every time.

I am running Fedora 22 x64.
Comment 4 Fedora Admin XMLRPC Client 2016-07-08 05:37:43 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 John C. Beima 2016-07-19 15:02:47 EDT
Just updating this to include Fedora 24 so it does not just get closed.

This still exists all his time later.
Comment 6 John C. Beima 2016-12-10 02:51:41 EST
This bug still exists in Fedora 25.

Very disappointed to see the complete and utter lack of quality in this application and lack of caring by it's maintainers.
Comment 7 Jaroslav Mracek 2017-04-18 11:19:18 EDT
I have good news because I cannot reproduce it anymore with dnf-2.3.0-1.git.3.33e4097.fc25.noarch, libdnf-0.8.1-2g8379fd9.fc25.x86_64. The dnf-2.3 was released into rawhide, but can be installed from out testing repository "dnf copr enable rpmsoftwaremanagement/dnf-nightly". Please if the problem appears with dnf-2.3 or later version, please don't hesitate to reopen the bug report. And I am sorry for so long time that you waited for solving the problem.

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