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)
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.
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.
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?
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.
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.
Yes, I think that is the case.
Since a rebuild is not necessary, I'm moving this to MODIFIED.
*** Bug 1000337 has been marked as a duplicate of this bug. ***
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.
We're really rarely adding multilib in Z-stream updates. Usually it needs to be explicitly acked by pm.
1055622 is about adding multilib Boost to Z-stream and was explicitly acked by pm (it has pm+). What more do you need?
(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.
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?
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.