RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 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 "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". 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 "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-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 834672 - package conflict when updating atlas on x86_64
Summary: package conflict when updating atlas on x86_64
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: releng
Version: 6.3
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Lubos Kocman
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-22 18:25 UTC by Fred Bacon
Modified: 2015-01-30 13:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-30 13:48:41 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
the original atlas placement from RHEL-6.0 (12.06 KB, text/plain)
2015-01-30 13:49 UTC, Lubos Kocman 		no flags Details
atlas placement from RHEL-6.3 (13.31 KB, text/plain)
2015-01-30 13:50 UTC, Lubos Kocman 		no flags Details
View All

Description Fred Bacon 2012-06-22 18:25:13 UTC 
Description of problem:

Attempting to update atlas.x86_64 from RHEL 6.2 to 6.3 causes yum to add atlas.i686 to the installation.  But the versions don't match.  The x86_64 package version is atlas-3.8.4-2.el6.x86_64, but the i686 version is atlas-3.8.4-1.el6.i686.  Yum shouldn't be trying to install atlas.i686 at all, since there are no other i686 packages installed on the system.

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

atlas-3.8.4-2.el6.x86_64
atlas-3.8.4-1.el6.i686

How reproducible:

This occurs whenever I attempt to perform an upgrade which includes atlas.

Steps to Reproduce:
1. With atlas-3.8.4-1.el6.x86_64 and atlas-devel-3.8.4-1.el6.x86_64 installed (perhaps even without!)

2. run yum update atlas.x86_64

  
Actual results:

The package is not installed.  The following output is generated.

Loaded plugins: changelog, downloadonly, presto, product-id, refresh-packagekit, rhnplugin, security, subscription-manager, versionlock
Updating certificate-based repositories.
Unable to read consumer identity
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package atlas.x86_64 0:3.8.4-1.el6 will be updated
--> Processing Dependency: atlas = 3.8.4-1.el6 for package: atlas-devel-3.8.4-1.el6.x86_64
---> Package atlas.x86_64 0:3.8.4-2.el6 will be an update
--> Running transaction check
---> Package atlas.i686 0:3.8.4-1.el6 will be installed
--> Processing Dependency: libpthread.so.0(GLIBC_2.1) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libpthread.so.0(GLIBC_2.0) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libpthread.so.0 for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libm.so.6(GLIBC_2.0) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libm.so.6 for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libgfortran.so.3(GFORTRAN_1.0) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libgfortran.so.3 for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.4) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.3.2) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.1.3) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.1) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.0) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6 for package: atlas-3.8.4-1.el6.i686
---> Package atlas.x86_64 0:3.8.4-1.el6 will be updated
--> Running transaction check
---> Package glibc.i686 0:2.12-1.80.el6 will be installed
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.80.el6.i686
--> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.80.el6.i686
---> Package libgfortran.i686 0:4.4.6-4.el6 will be installed
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.12.9-11.el6 will be installed
--> Finished Dependency Resolution
Error: Protected multilib versions: atlas-3.8.4-1.el6.i686 != atlas-3.8.4-2.el6.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


Expected results:

The new atlas and atlas-devel packages should be installed.


Additional info:
Comment 2 Fred Bacon 2012-06-22 18:52:32 UTC 
Well, apparently, someone at Redhat decided to rename the subscription channels for the new 6.3 release.  Atlas-devel was originally in the "Supplemental" channel and is now in the "Optional" channel.  This seems to have made the update difficult to perform since yum doesn't know about the new channel.

The resolution is to update everything except atlas and atlas-devel, add "Optional" to your channel subscriptions, and then perform the update for atlas.  That seems to have worked, but why the hell are atlas and atlas-devel in different channels to begin with?
Comment 3 Peter Schiffer 2012-06-25 12:38:44 UTC 
Fred,

atlas-devel package should always be in the "Optional" subscription channel. "Supplementary" channel is for software with non-standard SLAs and/or licenses.

Are you sure you just didn't disabled the "Optional" sub. channel between installing atlas-devel and updating it?

Thanks,

peter
Comment 4 Fred Bacon 2012-06-25 14:42:24 UTC 
Peter,

I didn't disable the optional channel, but I'm not the only admin with access to that account.  *sigh* It's possible that someone else did it, but it seems unlikely.  

Sorry for my irritable comment.  I spent five hours trying to strip off all of the i686 packages and staring at logs until I could figure out how to diagnose the problem with the update.  That's a lot of billable hours lost.

Fred
Comment 5 Peter Schiffer 2012-06-26 10:26:53 UTC 
Fred,

that's OK, I understand. However, I am not sure how we could help you now. Can you somehow determine that atlas-devel package wasn't in optional sub. channel before?

Thanks,

peter
Comment 6 RHEL Program Management 2012-09-07 05:29:10 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.
Comment 7 Frantisek Kluknavsky 2014-11-07 15:44:43 UTC 
Recent yum gives a nice clue:
"""
Error:  Multilib version problems found. This often means that the root
       cause is something else and multilib version checking is just
       pointing out that there is a problem. Eg.:
       
         1. You have an upgrade for atlas which is missing some
            dependency that another package requires. Yum is trying to
            solve this by installing an older version of atlas of the
            different architecture. If you exclude the bad architecture
            yum will tell you what the root cause is (which package
            requires what). You can try redoing the upgrade with
            --exclude atlas.otherarch ... this should give you an error
            message showing the root cause of the problem.
"""

As far as I can tell, atlas-devel in optional channel. Release engineering might know more.
Comment 8 Lubos Kocman 2015-01-30 13:48:41 UTC 
Hello,

I have to disagree about Supplementary channels. I just reviewed 6.0 and it was originally targeted for the optional channels and it was never part of Supplementary. See attachment of filelists from 6.0 and 6.3

$ find /mnt/redhat/released/RHEL-6-Supplementary --name "atlas*.rpm -type f
[lkocman@rcm-dev RHEL-6-Supplementary]$

I'd also like to note that optional vs RHEL Base can vary based on dependencies

Example: if something in RHEL Server requires atlas-devel then it will be in RHEL Server while it still might be in Client Optional ....


Closing as notabug. Since I can't think of anything else than accidental disabling optional channel.

Feel free to reopen this incident if you have further questions.

Thanks

Lubos
rel-eng
Comment 9 Lubos Kocman 2015-01-30 13:49:39 UTC 
Created attachment 985993 [details]
the original atlas placement from RHEL-6.0
Comment 10 Lubos Kocman 2015-01-30 13:50:06 UTC 
Created attachment 985995 [details]
atlas placement from RHEL-6.3
Note You need to log in before you can comment on or make changes to this bug.