Bug 983466

Summary: Incorrect parsing of provides with an empty epoch?
Product: [Community] Spacewalk Reporter: Lionel Le Folgoc <lionel>
Component: ServerAssignee: Michael Mráka <mmraka>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.8   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-18 09:58:58 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:
Bug Depends On:    
Bug Blocks: 1484117    
Attachments:
Description Flags
Log of failed upgrade
none
Direct install works none

Description Lionel Le Folgoc 2013-07-11 09:32:44 UTC 
Created attachment 772098 [details]
Log of failed upgrade

Hi,

There's a fc17 package (from rpmfusion) that provides "nvidia-304xx-kmod-common = :304.88". I have a spacewalk channel set up to synchronize with the upstream repository. Using spacewalk and yum-rhn-plugin, yum thinks that the provides isn't satisfied, thus is unable to find a clean upgrade path and fails with the following error (see attachments):

Error: Package: kmod-nvidia-304xx-3.9.8-100.fc17.i686.PAE-304.88-1.fc17.5.i686
(fedora17-i386-rpmfusion-nonfree)
           Requires: nvidia-304xx-kmod-common >= 304.88
           Installing: xorg-x11-drv-nvidia-304xx-304.88-8.fc17.i686
(fedora17-i386-rpmfusion-nonfree)
               nvidia-304xx-kmod-common = :304.88

It seems it doesn't like the empty epoch and doesn't parse it correctly.

A direct upgrade from the rpmfusion repository works fine ; same for a yum localinstall of this package (yum is able to resolve dependencies properly, see attachments).

(Note that it also affects kickstart installs, which fail to resolve the dependency as well.)

I compared the original primary.xml.gz repodata from rpmfusion (http://download1.rpmfusion.org/nonfree/fedora/updates/17/i386/repodata/) to the one provided by spacewalk after synchronization, and the epoch was changed from epoch="0" to epoch="" in the XML file for this package.

So I suppose the component responsible for parsing the rpm and generating repodata (taskomatic?) should replace an empty epoch by "0", otherwise it confuses the dependency resolver?

Thanks!

Rpmfusion bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2874

On the clients:
$ rpm -qa '*rhn*'
rhnmd-5.3.11-1.fc17.noarch
rhncfg-5.10.36-1.fc17.noarch
yum-rhn-plugin-1.8.8-1.fc17.noarch
rhn-custom-info-5.4.14-1.fc17.noarch
rhncfg-management-5.10.36-1.fc17.noarch
rhn-client-tools-1.8.26-1.fc17.noarch
rhncfg-client-5.10.36-1.fc17.noarch
rhn-setup-1.8.26-1.fc17.noarch
rhn-check-1.8.26-1.fc17.noarch
rhncfg-actions-5.10.36-1.fc17.noarch
rhnlib-2.5.55-1.fc17.noarch
rhnsd-5.0.4-1.fc17.i686

On the server:
# rpm -qa 'spacewalk*'
spacewalk-branding-1.8.7-1.el6.noarch
spacewalk-backend-xmlrpc-1.8.85-1.el6.noarch
spacewalk-backend-config-files-tool-1.8.85-1.el6.noarch
spacewalk-setup-jabberd-1.8.7-1.el6.noarch
spacewalk-monitoring-selinux-1.8.4-1.el6.noarch
spacewalk-repo-1.8-4.el6.noarch
spacewalk-slf4j-1.6.1-1.el6.noarch
spacewalk-backend-libs-1.8.85-1.el6.noarch
spacewalk-backend-sql-postgresql-1.8.85-1.el6.noarch
spacewalk-java-config-1.8.181-1.el6.noarch
spacewalk-selinux-1.8.2-1.el6.noarch
spacewalk-grail-1.8.49-1.el6.noarch
spacewalk-common-1.8.6-1.el6.noarch
spacewalk-monitoring-1.4.1-1.el6.noarch
spacewalk-base-1.8.49-1.el6.noarch
spacewalk-config-1.8.6-1.el6.noarch
spacewalk-backend-config-files-common-1.8.85-1.el6.noarch
spacewalk-backend-tools-1.8.85-1.el6.noarch
spacewalk-taskomatic-1.8.181-1.el6.noarch
spacewalk-backend-applet-1.8.85-1.el6.noarch
spacewalk-search-1.8.6-1.el6.noarch
spacewalk-setup-1.8.24-1.el6.noarch
spacewalk-sniglets-1.8.49-1.el6.noarch
spacewalk-java-1.8.181-1.el6.noarch
spacewalk-utils-1.8.33-1.el6.noarch
spacewalk-doc-indexes-1.1.1-1.el6.noarch
spacewalk-pxt-1.8.49-1.el6.noarch
spacewalk-admin-1.8.6-1.el6.noarch
spacewalk-certs-tools-1.8.4-1.el6.noarch
spacewalk-java-postgresql-1.8.181-1.el6.noarch
spacewalk-backend-server-1.8.85-1.el6.noarch
spacewalk-backend-app-1.8.85-1.el6.noarch
spacewalk-java-lib-1.8.181-1.el6.noarch
spacewalk-backend-config-files-1.8.85-1.el6.noarch
spacewalk-backend-iss-1.8.85-1.el6.noarch
spacewalk-schema-1.8.89-1.el6.noarch
spacewalk-base-minimal-1.8.49-1.el6.noarch
spacewalk-backend-1.8.85-1.el6.noarch
spacewalk-backend-sql-1.8.85-1.el6.noarch
spacewalk-backend-package-push-server-1.8.85-1.el6.noarch
spacewalk-postgresql-1.8.6-1.el6.noarch
spacewalk-backend-xml-export-libs-1.8.85-1.el6.noarch
spacewalk-backend-iss-export-1.8.85-1.el6.noarch
spacewalk-html-1.8.49-1.el6.noarch
spacewalk-jpp-workaround-1.0.4-1.el6.noarch
Comment 1 Lionel Le Folgoc 2013-07-11 09:35:50 UTC 
Created attachment 772099 [details]
Direct install works
Comment 2 Michael Mráka 2013-10-18 09:58:58 UTC 
Hello Lionel,

I've re-tested the above issue in Spacewalk 2.0 and it installs package just fine.
According to it I'm going to close this bug as fixed in CURRENTRELEASE.
If you disagree or there are some other important facts I might miss while reproducing the bug please reopen the bug.

Regards,
Michael
Comment 3 Eric Herget 2017-09-28 18:09:20 UTC 
This BZ closed some time during 2.5, 2.6 or 2.7.  Adding to 2.7 tracking bug.