boost-devel was filtered on purpose in Bug 675101. It was related to python one of them is python-boost. I'm not sure why boost-devel was filtered out as well.

I just modified distill configuration. Change should be visible in tomorrow's nightly

Lubos

Boost-devel brings in boost, which brings in boost-python, which brings in python-libs.  That's why, ultimately, we had to drop boost-devel if we don't ship python-libs.  _Some_ python-libs is available though, as can be seen above, albeit not the most recent one, which should be enough to satisfy the deps.

Luckily, boost-devel doesn't explicitly depend on boost-python (even though it probably should), so even if the customer won't be able to develop i386 Boost.Python apps on x86_64, the rest should work fine.

(In reply to Lubos Kocman from comment #2)
> boost-devel was filtered on purpose in Bug 675101. It was related to python
> one of them is python-boost. I'm not sure why boost-devel was filtered out
> as well.

I can't see Bug 675101, so I can't comment on the rationale for the exclusion. However, boost-devel requires libboost_python.so.5 and libboost_python-mt.so.5, so it drags in boost-python.

(In reply to Petr Machata from comment #3)
> Boost-devel brings in boost, which brings in boost-python, which brings in
> python-libs.  That's why, ultimately, we had to drop boost-devel if we don't
> ship python-libs.  _Some_ python-libs is available though, as can be seen
> above, albeit not the most recent one, which should be enough to satisfy the
> deps.

You can't mix python-libs versions, so unless you ship a match python-libs.i686 to the latest python-libs.x86_64, it will still be broken. python-libs, like most (all?) *-libs packages, has a hard-requirement for the base package of the same version. Again, I don't fully grok why you'd stop updating python-libs.i686.

The argument in bug 675101 is that it's not desirable to have 32-bit python on x86_64, because RPM wouldn't install two interpreters side by side anyway.  python-libs was somehow caught in this as well.  I'm not sure--is python-libs of any use without the interpreter, can scripts be invoked purely via python-libs?  It's unfortunate that removal of python-libs also means removal of almost 100 libraries shipped by boost-devel.

I'm adding Petr Šplíchal to CC, as he was one of the drivers of this change.  I hope he'll add a more qualified point of view as to what harm python-libs.i386 does.

I can understand not wanting python.i686 installed on an x86_64 system, since Python is a core dependency (e.g., Yum depends on it) and you want /usr/bin/python to be *right* python. However, python-libs is something totally different, as there are several projects that use libpython2.6.so to embed a Python interpreter, which is exactly what boost-python allows[1]. Currently, all of those packages are uninstallable due python-libs.i686 mismatching versions with the base python RPM.

# repoquery --whatrequires libpython2.6.so.1.0
PyKDE4-akonadi-0:4.3.4-5.el6.i686
PyQt4-0:4.6.2-8.el6.i686
boost-mpich2-python-0:1.41.0-11.el6.i686
boost-python-0:1.41.0-11.el6.i686
fontforge-0:20090622-2.1.el6.i686
glade3-libgladeui-0:3.6.7-2.1.el6.i686
gstreamer-python-0:0.10.16-1.1.el6.i686
iscsi-initiator-utils-0:6.2.0.872-10.el6.i686
kdeutils-libs-6:4.3.4-6.el6.i686
python-0:2.6.5-3.el6.i686
python-0:2.6.5-3.el6_0.2.i686
python-devel-0:2.6.5-3.el6.i686
python-devel-0:2.6.5-3.el6_0.2.i686
rhythmbox-0:0.12.8-1.el6.i686

If you include the greater community (EPEL), then the list of broken packages is larger:

# repoquery --repoid=epel --whatrequires libpython2.6.so.1.0
OpenColorIO-0:1.0.7-4.el6.i686
OpenImageIO-0:1.0.4-1.el6.i686
airinv-0:1.00.0-2.el6.i686
airrac-0:1.00.0-2.el6.i686
airsched-0:1.00.0-2.el6.i686
collectd-0:4.10.9-1.el6.i686
gnumeric-1:1.10.10-2.el6.1.i686
kvirc-0:4.2.0-3.el6.i686
plplot-tk-0:5.9.7-3.el6.1.i686
python-pyside-0:0.4.1-3.el6.i686
rekall-python-0:2.4.6-13.el6.i686
rmol-0:1.00.0-2.el6.i686
sevmgr-0:1.00.0-3.el6.i686
shiboken-libs-0:0.5.0-2.el6.i686
simcrs-0:1.00.0-2.el6.i686
simfqt-0:1.00.0-2.el6.i686
stdair-0:1.00.1-3.el6.i686
tomoe-0:0.6.0-19.el6.i686
trademgen-0:1.00.0-2.el6.i686
travelccm-0:1.00.1-2.el6.i686
unbound-libs-0:1.4.19-1.el6.i686
vtk-python-0:5.8.0-6.el6.1.i686

However, beyond all of that, I don't understand bug 675101 because the only way python.i686 causes a problem is if python.x86_64 is not installed. In which, if you install python.i686, it will end up being /usr/bin/python and cause havoc. However, to achieve that is a multi-step process that nobody should do. Let's not kill the patient to cure a cold. In fact, on downstream distros, they still deliver the i686 package, which makes sense to me, and I don't see lots of complaints about that.

[2] http://www.boost.org/doc/libs/1_41_0/libs/python/doc/tutorial/doc/html/python/embedding.html

Oh, it occurs to me that you need python.i686 to get the Python standard library, so that is probably the reason all of the python*.i686 packages were blocked.

Reverting the change and setting devel nack


[2013-08-26 01:56:16] ERROR: 47535683131712 task_resolve_deps.py:174 (s390x.Server) Unresolvable dependency libboost_python.so.5 in boost-devel.s390
[2013-08-26 01:56:16] ERROR: 47535683131712 task_resolve_deps.py:174 (s390x.Server) Unresolvable dependency libboost_python-mt.so.5 in boost-devel.s390
[2013-08-26 01:56:16] ERROR: 47535683131712 task_resolve_deps.py:174 (s390x.Server) Unresolvable dependency libboost_python.so.5 in boost-devel.s390
[2013-08-26 01:56:16] ERROR: 47535683131712 task_resolve_deps.py:174 (s390x.Server) Unresolvable dependency libboost_python-mt.so.5 in boost-devel.s390

Lubos

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

You didn't even reply to my comments, wherein I tried to argue against a ticket I can't even read. How can I address concerns from a ticket that is closed to the public? Also, you realize that you have broken the upgrade path for anyone who has already installed boost-devel.i686? (That's how I originally discovered the issue.) Beyond that, your product is inconsistent; there are 14 RPMs in *your* repository that currently are uninstallable due to not including python-libs.i686. I have another development box that is Scientific Linux 6, and this works perfectly fine, so I don't get it.

I don't have permissions on this tracker to re-open tickets, so that's a cute way to tell me to go away. Thanks.

Hello,

let me recheck the issue with other guys.

Lubos

Lubos,

Thanks for giving me a look at the other bug. So, I guess this ticket is mislabeled, because boost-devel was just collateral damage, and the real underlying issue is removing the i686 Python from x86_64.I think the solution discussed about pushing the Python stdlib into the python-libs subpackage made a lot of sense, and I wonder why that wasn't pursued instead of yanking out packages?

Thanks,
-Scott

*** Bug 1005370 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 1037680 ***