On Sat, 4 Jan 2020 16:18:44 +0000 Dimitri John Ledkov <dimitri.led...@surgut.co.uk> wrote: > I would be ok to reintroduce boost-python2.7 in experimental only.
> > On Sat, 4 Jan 2020, 06:45 Giovanni Mascellani, <g...@debian.org> wrote: > > > >> Hi, > >> > >> Il 03/01/20 22:07, Adrian Bunk ha scritto: > >> > Dimitri already agreed in a private discussion that this change was > >> bogus. > >> > > >> > > > > Hm?! I acknowledge it is an Abi Break, but it was intentional. We want to > > both drop python2 and drop boost1.67 from Sid and testing. > > > > Everything that uses or provides boost-python2.7 is RC in both testing and > > unstable. > > > Are there any objections against an NMU reverting the bogus Python 2 > >> > removal in boost1.67? > >> > >> Totally agree that there is no reason to remote Python 2 support from > >> boost1.67. Please do the NMU. This bug is not about the python2 removal. This bug is about removing a shared library without doing a proper transition, i.e. renaming the package (which will happen with boost1.71) or adding a bunch of Breaks. The same will happen again once python3.7 gets removed and only python3.8 remains as a supported version. (Similar bugs happened during the python3.6->python3.7 switch and prompted for the introduction of some virtual packages) To simplify such future transitions, I created a patch (#948273) to actually make use of the virtual packages introduced in -12. 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. 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. Andreas
