Bug 901833

Summary:	DNF can't handle packages with identified arch.
Product:	[Fedora] Fedora	Reporter:	Sander Salazar <sstsalazar>
Component:	dnf	Assignee:	Ales Kozumplik <akozumpl>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	18	CC:	akozumpl, jzeleny
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	dnf-0.2.21	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-02-21 05:52:23 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:
Embargoed:

Description Sander Salazar 2013-01-19 15:22:59 UTC

Description of problem:
 DNF fails to deliver any results for installs, removals and searches when a package is defined with an arch version(.i686, .x86_64, .noarch). 

Version-Release number of selected component (if applicable):
 dnf-0.2.17-1.git6a055e6.fc18.noarch
 dnf-0.2.17-1.git6a055e6.fc18.noarch
 python-hawkey.x86_64 0.3.3-1.git4e41b7f.fc18

How reproducible:
 100%

Steps to Reproduce:
 1. dnf search <package name> (List the packages and their different archs, if available)
 2.dnf install <package name> (Will install the package in the OS arch)
 3.dnf install <package name>.<arch> (Will fail to resolve dependencies)
  
Actual results:
 dnf install libgcc.i686
 Setting up Install Process
 Resolving Dependencies
 --> Starting dependency resolution
 --> Finished dependency resolution
Nothing to do


Expected results:
 Install the package like yum does.

Additional info:
 System updated on January 19 06:00 AM.

Comment 1 Ales Kozumplik 2013-01-21 07:17:31 UTC

Hello,

can you please try with the latest DNF from updates-testing and write here how that works for you? I've done some work in recognizing the user input patterns last month but it hasn't made it into F18 until this Friday.

Thanks,
Ales

Comment 2 Sander Salazar 2013-01-23 01:35:11 UTC

Hello Ales,

 I tested with both packages from the fedora repo and others repos and I have found only 3 "problems" so far. 

 The install, search, remove command are working flawlessly but the info presents some divergences from the yum's one, that are:

  1. Lacks the "From Repo:" field(in wine's case, fedora)
  2. In a non-installed package from the standard repositories, the "Repo:" field is presented as "<repo>/<version>/<arch>" (in wine's case fedora/18/x86_64), while yum presents it as "<repo>"(fedora) alone.
  3. In a non-installed package from a third-party, the "Repo: " field is presented as "@System", this includes the updates-testing's dnf. I tested with packages from Google's, Rpmfusion and Livna's repos.

I know that they can be only design changes, but I found them worth mentioning.

Steps to Reproduce:
1. yum info wine.i686
2. dnf info wine.i686

Expected results:

Installed Packages
Name        : wine
Arch        : i686
Version     : 1.5.18
Release     : 1.fc18
Size        : 0.0  
Repo        : installed
FROM REPO   : FEDORA
Summary     : A compatibility layer for windows applications
URL         : http://www.winehq.org/
License     : LGPLv2+
Description : Wine as a compatibility layer for UNIX to run Windows applications. This
            : package includes a program loader, which allows unmodified Windows
            : 3.x/9x/NT binaries to run on x86 and x86_64 Unixes. Wine can use native system
            : .dll files if they are available.
            : 
            : In Fedora wine is a meta-package which will install everything needed for wine
            : to work smoothly. Smaller setups can be achieved by installing some of the
            : wine-* sub packages.


Actual results:

Error: No matching Packages to list


Additional info:

dnf-0.2.20-1.gitdec970f.fc18.noarch in use.


Thanks for the good work, Ales.

Comment 3 Ales Kozumplik 2013-01-23 11:26:01 UTC

Thank you for the feedback. The missing repo names you are mentioning in comment 2 are a different issue then the one reported in this bug, no?

Comment 4 Sander Salazar 2013-01-23 11:49:43 UTC

Yes, they are different issue. I only added that because I thought it was somehow related to it. If you want, I may put it as a different bug.

I consider the bug fixed.

Comment 5 Ales Kozumplik 2013-01-23 12:13:25 UTC

Yes, please open a new bugzilla for the missing repo names.

I'll keep the current bug opened for a fix to the 'dnf info wine.i686' case --- that is actually related to the original issue.

Comment 6 Ales Kozumplik 2013-02-06 15:24:27 UTC

All list commands should now accepts name.arch and other NEVRA combinations as input arguments. Commit b499c6f.

Comment 7 Fedora Update System 2013-02-11 12:05:38 UTC

hawkey-0.3.7-2.gitdd10ac7.fc18, dnf-0.2.21-1.git050524e.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dnf-0.2.21-1.git050524e.fc18,hawkey-0.3.7-2.gitdd10ac7.fc18

Comment 8 Fedora Update System 2013-02-12 05:11:30 UTC

Package hawkey-0.3.7-2.gitdd10ac7.fc18, dnf-0.2.21-1.git050524e.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing hawkey-0.3.7-2.gitdd10ac7.fc18 dnf-0.2.21-1.git050524e.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-2318/dnf-0.2.21-1.git050524e.fc18,hawkey-0.3.7-2.gitdd10ac7.fc18
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2013-02-21 05:52:25 UTC

hawkey-0.3.7-2.gitdd10ac7.fc18, dnf-0.2.21-1.git050524e.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.