On 06/01/2020 15.20, Dimitri John Ledkov wrote: >> Please include it along with the reintroduction of python2 support in >> *sid*. Then we can binNMU all rdepends of libboost-python1.67.0, >> libboost-mpi-python1.67.0, libboost-numpy1.67.0 to add more strict >> dependencies on the required python support. > > I can see value in binNMU of rdepends such that boost-python3 using > apps get the right right versioned 3.x deps. > > But I'm struggling to understand what reintroducing python2 support in > *sid* aims to achieve, given that python2 support is to be removed > from *both* testing _and_ sid.
This would be easiest and quickest solution for the current problems while better options are implemented. > On upgrades, the old boost-python from stable will remain installed on > users systems, or get autoremoved. For that to work, libboost-python1.67.0 and friends need to be gone from sid (e.g. by renaming). Right now the version in sid has less features than the ones in stable and testing, but that is not reflected in dependencies. > I'd rather rename boost-python package to boost-python3 with virtual > versioned 3.x provides, without reintroducing python2 support and > simply leaving the old boost-python as NBS. > >> >> For the transition to boost1.71 it would be best if that happens before >> python3.8 is the only supported python3 and we can thus remove a >> boost1.67 still supporting python2.7 and python3.7 from sid. >> >> In the unlikely event that bullseye should ship boost1.67 (along 1.71+), >> we need to reinvestigate this to ensure partial upgrades from buster to >> bullseye don't break anything. Probably renaming the three binary >> packages to get a -python3 suffix would be easiest. > > Why not just do this now? I'd rather wait in the ftp-master NEW queue > today, than at some point in the future. It would be a valid solution to the current issue, too. I just thought we could avoid a probably unnneccessary transition. Andreas
