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 <g.mascell...@gmail.com> Postdoc researcher - Université Libre de Bruxelles
signature.asc
Description: OpenPGP digital signature
