On Mon, 2 Apr 2018 00:12:58 +0200 Dominik George <n...@naturalnet.de> wrote:
> > Your latest upload drops the python-pygame pacakge but I count 35
> > packages in Debian Testing that depend on it. Please restore the
> > python-pygame package until all those packages no longer depend on it.
> > Even without a bug being filed, I believe the broken dependency issue
> > would have prevented this package from migrating to Testing.
> So, what's the use of that?
> I do not target for testing - I target for buster and for sid. Neither
> pygame nor its dependencies, using Python 2, will survive the buster release
> cycle, so there is no point in forcefully keeping it around in testing. And
> as you said: Non of this will transition until the problem is solved (either
> by removal of the dependencies or their switch to Python 3).
> All that will happen with and without the Python 2 version of Pygame.
As Jeremy said, Python 2 will be shipped with buster, so all this seems
premature. But even if you were right, this is pretty rushed and uncoordinated.
A better way to handle this would be:
- Send a mail to debian-devel@ explaining this, with a list of rdeps
- Do a MBF (mass bug filing) against all the rdeps, asking to move to Python 3,
with severity important
- After enough time has passed, bump the severity to serious
- After some time, many unfixed rdeps will be auto-removed from testing
Then it would be time to drop python-pygame, as it would be easier to finish the
transition. This also means that during all these time, new versions of pygame
can transition to testing.
Of course the last two steps shouldn't happen during the buster cycle if
python2.7 isn't going to be dropped.
Right now all you are managing is to stall the new pygame version in unstable as
britney can't migrate it until all the rdeps are fixed or removed. So I'd
suggest to reintroduce python-pygame and to poke the rdeps so they start working