Bug 1000337
Summary: | boost-devel updates not shipped on secondary arches | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Petr Machata <pmachata> |
Component: | releng | Assignee: | Lubos Kocman <lkocman> |
Status: | CLOSED DUPLICATE | QA Contact: | Release Test Team <release-test-team-automation> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.5 | CC: | csieh, dgregor, jkejda, mganisin, misterbonnie, mnewsome, pmachata, psplicha, riehecky, scott |
Target Milestone: | rc | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-01-20 14:39:46 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 921792 |
Description
Petr Machata
2013-08-23 08:51:57 UTC
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 *** |