Re: Splitting source package into two
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
> 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
> 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.
BTW, if you are in contact with upstream, TLS on their domain seems a bit buggy.