Bug 1386921

Summary: "dnf info SUBPACKAGE" does not print the name of the source RPM
Product: [Fedora] Fedora Reporter: Laszlo Ersek <lersek>
Component: dnfAssignee: rpm-software-management
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: jmracek, lersek, mluscon, packaging-team-maint, pnemade, rpm-software-management, vmukhame
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-22 07:51:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Laszlo Ersek 2016-10-19 20:35:41 UTC
*** Description of problem:
When the user only knows the name of a subpackage, but not that of the main (source) package, and the subpackage is not installed on the system (so that "rpm -q --info" cannot be used), then "yum info SUBPACKAGE" used to provide this information (that is, leading the user from the subpackage to the main package). Dnf does not print this information.

*** Version-Release number of selected component (if applicable):
dnf-1.1.10-1.fc24.noarch

*** How reproducible:
100%

*** Example Steps to Reproduce:
1. On a Fedora 24 system,
   run "dnf info gcc-aarch64-linux-gnu"
2. On a RHEL-7 system with EPEL-7 enabled,
   run "yum info gcc-aarch64-linux-gnu"

*** Actual results:
The output of command #1 does not contain the "Source RPM" field.
The output of command #2 contains the "Source RPM" field
(namely cross-gcc-XXX.src.rpm).

*** Expected results:
"dnf info" should print the Source RPM field as well, because for some packages, the main package name cannot be deduced from the subpackage name.

*** Additional info:
If the subpackage is already installed on the system, or downloaded to a local file, then the command "rpm -q --info [-p SUBPACKAGE.rpm]" can be used to retrieve the same kind of information. However, the name of the SRPM should be retrievable without such restrictions.

Comment 1 Jaroslav Mracek 2016-10-21 16:11:28 UTC
I think that the problem was solved in DNF-2.0, that was released into rawhide. The testing version is available for fc24 in copr repo rpmsoftwaremanagement/dnf-nightly. Here I provide reduced output with and without verbose mode for dnf-2.0.0_0.rc1.1-11g5945ec5.fc24.noarch. Please can you confirm that you are satisfied with changes?

[bot]$sudo dnf info gcc-aarch64-linux-gnu -v
Last metadata expiration check: 2:54:09 ago on Fri Oct 21 15:13:14 2016 CEST.
Available Packages
Name         : gcc-aarch64-linux-gnu
Version      : 6.1.1
Release      : 2.fc24
Arch         : x86_64
Size         : 12 M
Source       : cross-gcc-6.1.1-2.fc24.src.rpm
Repo         : updates
Packager     : Fedora Project
Buildtime    : Fri Jul 08 17:00:13 2016 CEST
Summary      : Cross-build binary utilities for aarch64-linux-gnu
URL          : http://gcc.gnu.org
License      : GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and LGPLv2+ and BSD
Description  : Cross-build GNU C compiler.
             : 
             : Only building kernels is currently supported.  Support for cross-building
             : user space programs is not currently provided as that would massively multiply
             : the number of packages.

[bot]$ sudo dnf info gcc-aarch64-linux-gnu
Failed loading plugin: module
Last metadata expiration check: 2:54:20 ago on Fri Oct 21 15:13:14 2016 CEST.
Available Packages
Name         : gcc-aarch64-linux-gnu
Version      : 6.1.1
Release      : 2.fc24
Arch         : x86_64
Size         : 12 M
Source       : cross-gcc-6.1.1-2.fc24.src.rpm
Repo         : updates
Summary      : Cross-build binary utilities for aarch64-linux-gnu
URL          : http://gcc.gnu.org
License      : GPLv3+ and GPLv3+ with exceptions and GPLv2+ with exceptions and LGPLv2+ and BSD
Description  : Cross-build GNU C compiler.
             : 
             : Only building kernels is currently supported.  Support for cross-building
             : user space programs is not currently provided as that would massively multiply
             : the number of packages.

Comment 2 Laszlo Ersek 2016-10-21 17:20:52 UTC
Looks perfect. Printing the Packager in the verbose view is a nice touch also; that's something that yum prints as well, IIRC.

So I guess this BZ can be set to CLOSED/NEXTRELEASE, can it not?

Thank you very much!