Bug 1037680 - boost-devel i686 and x86_64 bit packages on RHEL-6
Summary: boost-devel i686 and x86_64 bit packages on RHEL-6
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: boost
Version: 6.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Petr Machata
QA Contact: Miroslav Franc
: 1000337 (view as bug list)
Depends On: 958256
Blocks: 921792 1033111 1055621 1055622
TreeView+ depends on / blocked
Reported: 2013-12-03 15:20 UTC by Jan Kepler
Modified: 2019-07-11 07:48 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Due to the way the Python programming language was packaged for Red Hat Enterprise Linux, the boost packages could not be shipped to secondary architectures. For example, boost-devel.i686 was not available on the x86-64 architecture. The Python packaging has been updated, and it is now possible to install secondary-architecture versions of the boost packages.
Clone Of:
Last Closed: 2014-10-14 06:22:26 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1440 normal SHIPPED_LIVE boost bug fix and enhancement update 2014-10-14 01:05:56 UTC

Description Jan Kepler 2013-12-03 15:20:45 UTC
Description of problem:
Missing boost-devel i686.

This is only part of the solution for Case 00750863 on RHCP.

Other part of the solution is python multilib https://bugzilla.redhat.com/show_bug.cgi?id=958256

Now we have only x86_64 version in the channel for RHEL Server (v. 6 for 64-bit x86_64)

Comment 2 Jan Kepler 2013-12-03 15:41:14 UTC
We already have erratum for python multilib part:

So I think now we are missing erratum for boost (this bug) with dependency on python erratum.

Comment 3 RHEL Program Management 2013-12-03 15:43:17 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 4 Petr Machata 2013-12-03 22:53:30 UTC
It seems that the Python package needed real actual changes to be shippable to the lesser arches.  There's no such concern for Boost--the packages have been built, it's just a matter of shipping those existing packages to customers.  Do we really need an erratum for this?  If yes, do we also need to rebuild, or can we just ship a partial erratum for i686?

Comment 7 Lubos Kocman 2014-01-10 10:39:41 UTC
Hello Petr,

so far we need to push packages to given channels. And there is a policy that we should stick to rpm->errata mapping. There is no need to rebuild-package. We can simply create new errata which says adding multilib and repush the same bits but to additional channels. That would be fine with me.


Comment 9 Lubos Kocman 2014-01-20 08:44:38 UTC
So far Jan Kejda tested installation of boost-devel and boost-python. So we know it should be safe to install these as multilib.

Seems like others were blacklisted just due dependency issues with python multilib which is now solved.

Comment 10 Petr Machata 2014-01-20 14:20:46 UTC
Yes, I think that is the case.

Since a rebuild is not necessary, I'm moving this to MODIFIED.

Comment 11 Petr Machata 2014-01-20 14:39:46 UTC
*** Bug 1000337 has been marked as a duplicate of this bug. ***

Comment 13 Scott Dial 2014-01-20 16:47:30 UTC
Since I reported #1000337, my workaround for our developers has been to reposync the i386 channels and to provide a private yum repo that provides boost*.i686 and python*.i686. So, I'm not sure there ever was a real problem for multilib on x86_64/i686. I have been installing, running, and upgrading systems like that for several months now. I never was able to reproduce the failure mode reported in #675101 (which refers to an issue on ppc64), which I was told was the reason python.i686 was blocked on x86_64.

Comment 22 Lubos Kocman 2014-02-06 13:21:52 UTC
We're really rarely adding multilib in Z-stream updates. Usually it needs to be explicitly acked by pm.


Comment 23 Petr Machata 2014-02-07 09:06:32 UTC
1055622 is about adding multilib Boost to Z-stream and was explicitly acked by pm (it has pm+).  What more do you need?

Comment 24 Petr Machata 2014-02-22 02:37:05 UTC
(In reply to Petr Machata from comment #23)
> 1055622 is about adding multilib Boost to Z-stream and was explicitly acked
> by pm (it has pm+).  What more do you need?

FWIW, I really wish to know the answer to this one.

Comment 25 Lubos Kocman 2014-03-12 13:45:55 UTC
Well this one is tricky and I'm personally against it. So far it does not seem to be required by these other multilibs and it also looks like we never had it explicitly as mulitlib (nor was blacklisted).

Or do we have requirement for it?

Comment 37 errata-xmlrpc 2014-10-14 06:22:26 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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