Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1312016 - Yum dependency issue, openscap.i686 is unavailable in Satellite Tools 6.1 repo
Summary: Yum dependency issue, openscap.i686 is unavailable in Satellite Tools 6.1 repo
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: SCAP Plugin
Version: 6.1.6
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: Unspecified
Assignee: satellite6-bugs
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-25 14:21 UTC by jalviso
Modified: 2019-10-10 11:20 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-03 06:50:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
openscap install error (15.70 KB, text/plain)
2016-02-25 14:22 UTC, jalviso
no flags Details

Description jalviso 2016-02-25 14:21:43 UTC
Description of problem:

When installing a package to a Content Host that has openscap as dependency, it installs x86_64 from RHEL6 rpms repo (latest "openscap-1.0.10-3.el6") but when .i686 is installed, it looks for "openscap-1.2.4-1.el6_6sat.x86_64" available from "Satellite Tools 6.1" repo but fails due to:

Protected multilib versions: openscap-1.2.4-1.el6_6sat.x86_64 != openscap-1.0.10-3.el6.i686

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


How reproducible: Always


Steps to Reproduce:
1. Register a RHEL6 Content Host and attach to a Content View that is recently
   synced with and update:
   rhel-6-server-rpms
   rhel-6-server-satellite-tools-6.1-rpms
2. Install i386/i686 rpms (example, some third party monitoring rpm's)
3. Install a package that has openscap as dependent package:
  
 # yum install preupgrade-assistant

Actual results:

Protected multilib versions: openscap-1.2.4-1.el6_6sat.x86_64 != openscap-1.0.10-3.el6.i686

a. openscap-1.0.8-1 will be installed as dependent package of 
    preupgrade-assistant-2.1.1-5.el6.x86_64
b. Then it upgrades to openscap-1.0.10-3.el6.x86_64 and installs
   openscap-1.0.10-3.el6.i686 (latest version available in RHEL6 RPMS repo)
c. But since a later version is available in Satellite Tools 6.1 repo, it  
   installs it, "openscap-1.2.4-1.el6_6sat.x86_64" but no matching .i686 version

See complete output attach, "openscap.i386"

Expected results:

It should install "openscap-1.2.4-1.el6_6sat.i686" but there is none available.

Additional info:

Comment 1 jalviso 2016-02-25 14:22:44 UTC
Created attachment 1130558 [details]
openscap install error

Comment 2 Bryan Kearney 2016-07-26 19:03:28 UTC
Moving 6.2 bugs out to sat-backlog.

Comment 3 Marek Hulan 2016-09-12 08:04:19 UTC
It seems that openscap-1.2.8-2.el6 was released during RHEL-6.8 GA (via RHEA-2016:0806) which should now install instead. Could you please check if it's still an issue after upgrade to 6.8?

Comment 5 Marek Hulan 2016-10-03 06:50:12 UTC
we got confirmed that this is no longer an issue


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