Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
Il 08/01/20 00:14, Andreas Beckmann ha scritto: > since python2.7 is back in boost-python and my shlibs patch is in, too, > I've requested a "transition" to get the binNMUs done to tighten the > boost-python dependencies: https://bugs.debian.org/948378 Great, thanks. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
Hi all, since python2.7 is back in boost-python and my shlibs patch is in, too, I've requested a "transition" to get the binNMUs done to tighten the boost-python dependencies: https://bugs.debian.org/948378 Andreas
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
On 06/01/2020 18.19, Giovanni Mascellani wrote: >> 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. > > So, if I get this right, the point of binNMU-ing is to make sure that > all the rev deps choose their versioned dependency, so that when a > Python version goes away the breakage will be recorded in the packages > dependencies (and won't be an actual breakage). Is this right? Yes. Packages depending on (virtual) libboost-python1.67.0-py37 will not be installable with a libboost-python1.67.0 that no longer provides that virtual package (and no longer ships the corresponding shared library). It needs a proper transition (likely part of a future python3.7-rm transition) to drop these dependencies (in favor of -py38 ones) and get everything migrated to testing. > And then you need to have Boost.Python with Python 2.7 back because > otherwise binNMUs will just fail, right? Some might fail, some might just drop python2.7 dependencies. But ... > If so, then I agree. If not, please explain me, because I am still > learning this kind of things. > >> 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. > > Why this? ... I'm more worried about smooth upgrades from buster to bullseye. If we have a libboost-python1.67.0 in testing that is missing features that were available in buster (worst case bullseye supports only py38, while buster supports only py27, py37), but that is installable in buster, it will silently break packages in buster. Even if this only happens for a short time during the upgrade (new libboost-python1.67.0 gets unpacked, I'm quite sure to run into it in some strange upgrade path during a piuparts test. ;-) Therefore it would be best if libboost-python1.67.0 is gone from testing (e.g. by renaming) before it loses "features" compared to buster. Andreas
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
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
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
Hi, Il 06/01/20 13:54, Andreas Beckmann ha scritto: > 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) I agree. > 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. So, if I get this right, the point of binNMU-ing is to make sure that all the rev deps choose their versioned dependency, so that when a Python version goes away the breakage will be recorded in the packages dependencies (and won't be an actual breakage). Is this right? And then you need to have Boost.Python with Python 2.7 back because otherwise binNMUs will just fail, right? If so, then I agree. If not, please explain me, because I am still learning this kind of things. > 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. Why this? Anyway, I started filing bugs for transitioning to Boost 1.71[1]. It will take some time, though. [1] https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=team%2Bboost%40tracker.debian.org&tag=boost1.71 > 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. Again, I am not sure of what is actually going on here, but I really hope this will not happen. Thanks, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
On Mon, 6 Jan 2020 at 12:54, Andreas Beckmann wrote: > > On Sat, 4 Jan 2020 16:18:44 + Dimitri John Ledkov > wrote: > > I would be ok to reintroduce boost-python2.7 in experimental only. > > > > On Sat, 4 Jan 2020, 06:45 Giovanni Mascellani, 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.
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
On Sat, 4 Jan 2020 16:18:44 + Dimitri John Ledkov wrote: > I would be ok to reintroduce boost-python2.7 in experimental only. > > On Sat, 4 Jan 2020, 06:45 Giovanni Mascellani, 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
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
I would be ok to reintroduce boost-python2.7 in experimental only. On Sat, 4 Jan 2020, 16:16 Dimitri John Ledkov, wrote: > > > On Sat, 4 Jan 2020, 06:45 Giovanni Mascellani, 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. > > Thus yeah, I do object to reintroducing python2 support in any boost > packages. > > Doing that will simply block 1.71 transition, and 1.67 removal. > > Python2 is dead :-) > > > 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. >> >> >> Giovanni. >> -- >> Giovanni Mascellani >> Postdoc researcher - Université Libre de Bruxelles >> >>
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
On Sat, 4 Jan 2020, 06:45 Giovanni Mascellani, 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. Thus yeah, I do object to reintroducing python2 support in any boost packages. Doing that will simply block 1.71 transition, and 1.67 removal. Python2 is dead :-) > 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. > > > Giovanni. > -- > Giovanni Mascellani > Postdoc researcher - Université Libre de Bruxelles > >
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
Hi, Il 03/01/20 22:07, Adrian Bunk ha scritto: > Dimitri already agreed in a private discussion that this change was bogus. > > 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. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#945840: libboost-python1.67.0 must not drop the Python 2.7 library
Control: reopen -1 Control: reassign -1 libboost-python1.67.0 1.67.0-14 Control: retitle -1 libboost-python1.67.0 must not drop the Python 2.7 library When a library package renames or drops a library it has to be removed. In practice this will happen in the boost case with the transition to 1.71. One real-world problem is that right now upgrading in a stable installation to the libboost-python1.67.0 package in unstable would cause runtime breakage in stable, and it would be even worse if the broken boost would enter testing. Dimitri already agreed in a private discussion that this change was bogus. Are there any objections against an NMU reverting the bogus Python 2 removal in boost1.67? cu Adrian
