Bug 799636 - openssl library split creates update headaches on x86_64
Summary: openssl library split creates update headaches on x86_64
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-03 18:19 UTC by Michal Jaegermann
Modified: 2012-03-07 08:27 UTC (History)
1 user (show)

Fixed In Version: openssl-1.0.1-0.3.beta3.fc18
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-07 08:27:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2012-03-03 18:19:59 UTC
Description of problem:

There are pretty good chances that x86_64 installation has both openssl.x86_64 and openssl.i686 present due to dependency requirements of other packages. An attempt to update that to openssl-1.0.1-0.2.beta3 packages bumps into "protected multilib" errors because a corresponding version of openssl.i686 is no longer available.  At least in those cases where I looked missing dependencies would be provided by openssl-libs.i686 but there is nothing which would cause that switch and yum gives up and abandons the whole transaction which would include mulitilib openssl updates.  It is possible to work around that "manually" but that is beyond GUI tools capabilities.

I am not sure how anaconda would handle that on distro upgrades.  Most likely this will be a serious obstacle with 'yum distro-sync ....'.

Is there a reasonable way to help yum to deal with the issue?  Maybe to make openssl-libs to obsolete older versions of openssl?  If openssl itself would be needed due to dependencies it will be updated anyway, I would think.  Hm, with a new version of openssl for a given architecture available it would get updated anyway, no?

Version-Release number of selected component (if applicable):
openssl-1.0.1-0.2.beta3

Comment 1 Tomas Mraz 2012-03-05 07:30:44 UTC
I suppose that yum update (without explicit specification of a single package) on a repository that contains both updated x86_64 and i686 packages would work correctly. However you're right that if you ask explicitly 'yum update openssl' this will not work. I'll try it with adding the obsoletes, perhaps it will help.

Comment 2 Michal Jaegermann 2012-03-05 15:19:06 UTC
(In reply to comment #1)
> I suppose that yum update (without explicit specification of a single package)
> on a repository that contains both updated x86_64 and i686 packages would work
> correctly.

Well, no, it does not.  At least not in the current state.  I bumped into that
running a rawhide update with a lot of packages in it and the whole transaction
was blocked due to this "protected multilib".  That despite that
openssl-libs.x86_64 and openssl-libs.i686 were available in repositories. I checked.  Still yum attempted to get openssl.i686 in updates, failed to find a version corresponding to an update of openssl.x86_64 and chocked on the whole transaction. A presence of '--skip-broken' was, not surprisingly, of no help.

This was rawhide so the simplest workaround was 'yum remove openssl.i686' with had no serious side-effects.  A more subtle approach woule need 'yum shell'.

> However you're right that if you ask explicitly 'yum update openssl'
> this will not work.

That will not work too.

Comment 3 Michal Jaegermann 2012-03-06 20:39:35 UTC
(In reply to comment #1)
> I'll try it with adding the obsoletes, perhaps it will help.

It looks to me that it does help. My test was limited to '--force' installing
openssl-1.0.1-0.1.beta2.fc17.i686.rpm on an x86_64 setup.  With openssl-libs which now have "openssl < 1:1.0.1-0.3.beta3" in obsoletes I got in yum:

Installing:
 openssl-libs                   i686      1:1.0.1-0.3.beta3.fc18     rawhide    821 k
     replacing  openssl.i686 1.0.1-0.1.beta2.fc17
 openssl-libs                   x86_64    1:1.0.1-0.3.beta3.fc18     rawhide    826 k
     replacing  openssl.i686 1.0.1-0.1.beta2.fc17
     replacing  openssl.x86_64 1:1.0.1-0.2.beta3.fc18

and openssl.x86_64 was installed too due to dependencies.  This appears to be a desired outcome.

Comment 4 Tomas Mraz 2012-03-07 08:27:28 UTC
That's great.


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