On Mon, 6 Jan 2020 at 12:54, Andreas Beckmann <a...@debian.org> wrote: > > 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.
That patch is nice, and indeed is the missing piece to sanely drop python abis. > 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. On upgrades, the old boost-python from stable will remain installed on users systems, or get autoremoved. 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. -- Regards, Dimitri.
