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
