On Thu, Jan 11, 2018 at 3:45 PM, Ole Streicher wrote: > Recently, upstream announced a new version 3.0 of astropy, which > supports Python 3 only, and I want to have a smooth migration path. I > thought of a temporary package split: create a new source package > "astropy" that inherits of the current python-astropy package, but only > builds python3-astropy (and the utils + doc, which depend on > python3-astropy), and update this to version 3.0. Then I would remove > these binary packages from the python-astropy package.
Sounds like a good plan to me, especially since the upstream project is 'astropy'. > The question is now: what I have to do in which order to do that? When I > upload a new "astropy" package, it offers the same Python 3 package as > the (still existing) python-astropy package, but with a higher > version. Is this a problem? Or need I to upload an updated > python-astropy package (with the Python 3 content removed) first? I think you should upload src:astropy taking over the python3-astropy package before uploading src:python-astropy to drop python3-astropy. This way you avoid making the reverse dependencies temporarily uninstallable. I think you still need a trip through NEW for the new src:astropy package though. After src:astropy is accepted, there will be two versions of python3-astropy in unstable. I believe the python3-astropy from src:python-astropy will get removed by the automated decrufting process, once you drop it from the src:python-astropy package. > How should one then handle their reverse dependencies? With the above plan, this is basically almost the same as a normal Python API transition. You will need to ensure that the reverse deps don't unconditionally use any of the removed APIs and are compatible with any of the changed APIs, if there are any of either. https://wiki.debian.org/Teams/ReleaseTeam/Transitions BTW, if you are in contact with upstream, TLS on their domain seems a bit buggy. -- bye, pabs https://wiki.debian.org/PaulWise
