Description of problem: Recently, Python 3.6 has become the minimum version for Python 3 on RHEL/CentOS 7 through EPEL repositories (https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/EGUMKAIMPK2UD5VSHXM53BH2MBDGDWMO/). On the other hand, since Boost (https://git.centos.org/rpms/boost) is a core component on RHEL/CentOS, it is not managed through EPEL, and as a consequence has not been upgraded in the process. In other words, Boost.Python3 (v1.53) on RHEL/CentOS 7 has been built against Python 3.4 and ships python34 dependent sub-packages, whereas it should now be built against Python 3.6 and ships python36 dependent sub-packages. That inconsistency in Python 3 dependencies leads to linking errors for projects using Boost.Python3. For instance, the full logs of such a built is: https://cloud.docker.com/u/tvlsim/repository/registry-1.docker.io/tvlsim/metasim/builds/9512a39d-b980-4611-87c4-162518aeeea2 Boost (1.53) on RHEL would need to be re-built against Python 3.6, and the corresponding Version-Release number of selected component (if applicable): boost-python34-1.53.0-28.el7.x86_64 and boost-python34-devel-1.53.0-28.el7.x86_64 on RHEL/CentOS 7.6+ How reproducible: Always Steps to Reproduce: 1. Have some code using Boost.Python3. Build and link against both boost-python34 and python36 2. 3. Actual results: There is a link error, where either the python36 or python34 symbols cannot be found Expected results: Only python36 libraries should be involved, and the linking process should complete without error Additional info: * Announce on the EPEL billboard/mailing list about Python 3.4 to Python 3.6 move: https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproject.org/thread/EGUMKAIMPK2UD5VSHXM53BH2MBDGDWMO/ * Boost source code on CentOS Git repository: https://git.centos.org/rpms/boost * Build logs for a project (namely, TvlSim, https://github.com/airsim/metasim) using Boost.Python3: https://cloud.docker.com/u/tvlsim/repository/registry-1.docker.io/tvlsim/metasim/builds/9512a39d-b980-4611-87c4-162518aeeea2
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)