[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Splitting source package into two


I am the maintainer of the "python-astropy" package, that currently
creates packages for both Python 2 and Python 3. Both packages have a
number of reverse dependencies.

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.

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? How
should one then handle their reverse dependencies?

(The question whether it is useful to have both python 2 and python 3 is
discussed in the d-python mailing list.)

Best regards


Reply to: