Bug 1702242
Summary: | Boost Python needs to be upgraded to boost-python36 after Python 3.6 has become the default | ||
---|---|---|---|
Product: | [Fedora] Fedora EPEL | Reporter: | Denis Arnaud <denis.arnaud_fedora> |
Component: | boost169 | Assignee: | Denis Arnaud <denis.arnaud_fedora> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | epel7 | CC: | denis.arnaud_fedora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | No Doc Update | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-05-10 11:39:21 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: |
Description
Denis Arnaud
2019-04-23 09:58:31 UTC
But EPEL is entirely optional, how can a core RHEL 7 package depend on python36 from EPEL? None of the other boost-* subpackages in RHEL 7 depend on boost-python3, so isn't the correct solution for EPEL to provide a boost-python36 package that can be installed by EPEL users, instead of using boost-python3? (In reply to Jonathan Wakely from comment #2) > But EPEL is entirely optional, how can a core RHEL 7 package depend on > python36 from EPEL? > > None of the other boost-* subpackages in RHEL 7 depend on boost-python3, so > isn't the correct solution for EPEL to provide a boost-python36 package that > can be installed by EPEL users, instead of using boost-python3? You are absolutely right, and I wondered where to report that issue. Your suggestion seems the good one, but I do not know how to add sub-packages in EPEL to an existing core package in RHEL/CentOS. Do you know the procedure? Another option is to bring the Python36 packages into core RHEL/CentOS. Yet another solution is to move out Boost from the RHEL/CentOS core packages into EPEL. How many of the packages depending on Boost are still core to RHEL/CentOS? (In reply to Denis Arnaud from comment #3) > You are absolutely right, and I wondered where to report that issue. Your > suggestion seems the good one, but I do not know how to add sub-packages in > EPEL to an existing core package in RHEL/CentOS. Do you know the procedure? Just add a completely new boost-python36 package to EPEL, not as a subpackage of anything. Users can choose whether to install the system boost-python3 or the EPEL boost-python36 (or both, as ideally they'd be able to coexist, and the user would choose one when linking their code). > Another option is to bring the Python36 packages into core RHEL/CentOS. I doubt that is in scope for RHEL 7. > Yet another solution is to move out Boost from the RHEL/CentOS core packages > into EPEL. How many of the packages depending on Boost are still core to > RHEL/CentOS? Our RHEL 7 customers who don't use EPEL would lose access to the packages. I doubt that would be acceptable. As writing the RPM specification file for a new Boost.Python36 package may not be that easy, switching to an upgraded/rebuilt version of EPEL-provided Boost169 is much easier/more straightforward. Also, I have just submitted a new update of Boost169: https://bodhi.fedoraproject.org/updates/boost169-1.69.0-2.el7 As this is not a RHEL bug, could you please set the Product to EPEL? There seems to be a boost-python3 component for EPEL. Is there a boost-python3 package in CentOS at all? Doesn't it only have boost-python? This bug is showing up on our dashboards for RHEL7 but I don't see anything relevant to RHEL7 here. (In reply to Jonathan Wakely from comment #7) > Is there a boost-python3 package in CentOS at all? Doesn't it only have > boost-python? As far as I can tell, there is/was a boost-python34 package on CentOS 7: $ rpm -qa | grep boost-python boost-python-1.53.0-27.el7.x86_64 boost-python34-1.53.0-28.el7.x86_64 I am not sure where it comes from, as the specification explicitly mentions boost-python3 (https://git.centos.org/rpms/boost/blob/c7/f/SPECS/boost.spec#_361). But, apparently, that CentOS-hosted Git repository does not have the latest versions (1.53.0-30, if I get it correctly): https://git.centos.org/rpms/boost/blob/c7/f/SPECS/boost.spec#_37 and https://git.centos.org/rpms/boost/blob/c7/f/SPECS/boost.spec#_1275 stopped at 1.53.0-27 So, I do not know what sources are used to produce boost-1.53.0-30 packages. Oops, I just removed boost-python34 and re-installed boost-python36-devel, and now it works (but, you are right, boost-python3 can not be installed without fully specifying -python36): $ rpm -qa|grep boost-python3 boost-python36-devel-1.53.0-30.el7.x86_64 boost-python36-1.53.0-30.el7.x86_64 > This bug is showing up on our dashboards for RHEL7 but I don't see anything > relevant to RHEL7 here. boost169 will reach the stable repository tomorrow or the day after, and that ticket will be automatically closed by Bodhi I guess: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f48be7619f boost169-1.69.0-2.el7 has been pushed to EPEL 7 stable repositories (https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f48be7619f) That ticket can be closed. I don't think Bodhi can close RHEL tickets. Changing Product and Component. Thanks, I could not do it myself (I've not the right to change RHEL tickets) |