Bug 1767503

(In reply to Petr Viktorin from comment #0)
> What would you say to removing boost-numpy2, boost-mpich-python2,
> boost-openmpi-python3 (and their -devel), but keeping boost-python2 and
> boost-python2-devel for Fedora 32?

The reason that Boost hasn't been updated for F31 is because the dual Python2 + Python3 build is a nightmare. Dropping python2 support entirely would make me very happy.

I'm not sure only dropping the MPI parts and keeping boost-python2 will help, but I can try it. It's unlikely to make things any worse than they are now.

Thanks for the response! I'll let the other maintainers know. (It's possible they'll not be interested; don't do the work yet.)

I have read a few times, in the recent discussions about modularity on the Fedora development mailing list, that in such cases we could potentially use so-called compatibility packages. That is, if I understand correctly, boost-python2 and boost-python2-devel would be tagged/marked/named as compatibility packages, no gong through any rebuild any more, while the whole Boost (1.71 first and 1.72 then) would be built without support for Python 2 at all.
I may have missed something, though.

 python2 (actually, "python27") is an example of a compatibility package :)

For boost, there would need to be a compatibility package for all of boost-1.69 (with boost1.69-python2 and boost1.69-python2-devel subpackages).
Probably doable, but it would need care so it doesn't conflict with the regular boost at the filesystem level.
And, there's no reason the boost maintainer(s) would need to package it. Would you like to try?

(In reply to Petr Viktorin from comment #4)
>  python2 (actually, "python27") is an example of a compatibility package :)
> 
> For boost, there would need to be a compatibility package for all of
> boost-1.69 (with boost1.69-python2 and boost1.69-python2-devel subpackages).
> Probably doable, but it would need care so it doesn't conflict with the
> regular boost at the filesystem level.
> And, there's no reason the boost maintainer(s) would need to package it.
> Would you like to try?

As a matter of fact, I already maintain such a package: https://src.fedoraproject.org/rpms/boost169
It was first intended as forward compatibility package for EPEL, where Boost often lags behind. But there is no reason it could not be used the same way for backward compatibility on Fedora. I have just launched build on EPEL 8 (similar enough to Fedora these days): https://koji.fedoraproject.org/koji/taskinfo?taskID=38709197
If you confirm it is an interesting option, I can of course build it for Rawhide too.

Wow! That does seem like a good way forward:

boost: Update to a newer boost AND drop python2 support in Rawhide
boost169: Build without python3, mpi, numpy (but with python2)
freeorion and k3d: Build with boost169-python2

... and then update all that at the same time.

Jonathan, Link, Ralf: does that sound reasonable?

(Successful) Build of Boost169 on Fedora Rawhide (32): https://koji.fedoraproject.org/koji/taskinfo?taskID=38709417 =>
* boost169-python2: https://kojipkgs.fedoraproject.org//work/tasks/9428/38709428/boost169-python2-1.69.0-3.fc32.aarch64.rpm
* boostt169-python2-devel: https://kojipkgs.fedoraproject.org//work/tasks/9428/38709428/boost169-python2-devel-1.69.0-3.fc32.aarch64.rpm

An example of project making use of such a boostNNN package on EPEL 6 is AirInv (https://src.fedoraproject.org/rpms/airinv). The corresponding CMake configuration details appear in the RPM spec file (https://src.fedoraproject.org/rpms/airinv/blob/el6/f/airinv.spec#_68):
 %build
 mkdir -p build
 pushd build
 %cmake -DBOOST_LIBRARYDIR=%{_libdir}/boost148 \
  -DBOOST_INCLUDEDIR=%{_includedir}/boost148 \
  -DBoost_ADDITIONAL_VERSIONS="1.48 1.48.0" ..
 make %{?_smp_mflags}
 popd

Sounds good to me.

(In reply to Petr Viktorin from comment #6)
> Wow! That does seem like a good way forward:
> 
> boost: Update to a newer boost AND drop python2 support in Rawhide
> boost169: Build without python3, mpi, numpy (but with python2)
> freeorion and k3d: Build with boost169-python2
> 
> ... and then update all that at the same time.
> 
> Jonathan, Link, Ralf: does that sound reasonable?

This should be feasible.

PRs for the two dependent packages:
    - https://src.fedoraproject.org/rpms/k3d/pull-request/1
    - https://src.fedoraproject.org/rpms/freeorion/pull-request/1

Jonathan, that should free you to drop Python 2 support in the main boost package.

https://bodhi.fedoraproject.org/updates/FEDORA-2019-3774079aa7 drops support for Python 2 (and python2 sub-packages)

This is great, thanks everybody!