Bug 983466 - Incorrect parsing of provides with an empty epoch?
Summary: Incorrect parsing of provides with an empty epoch?
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 1.8
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Michael Mráka
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space27
TreeView+ depends on / blocked
 
Reported: 2013-07-11 09:32 UTC by Lionel Le Folgoc
Modified: 2017-09-28 18:09 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-18 09:58:58 UTC
Embargoed:


Attachments (Terms of Use)
Log of failed upgrade (18.51 KB, text/plain)
2013-07-11 09:32 UTC, Lionel Le Folgoc
no flags Details
Direct install works (4.12 KB, text/plain)
2013-07-11 09:35 UTC, Lionel Le Folgoc
no flags Details

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.


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