On 7/8/19 6:28 PM, Stewart Ferguson wrote: > On 2019-07-08 00:13:45, Thomas Goirand wrote: >> On 7/7/19 5:31 PM, Matthias Klose wrote: >>> you can start dropping it now, however please don't drop anything yet with >>> reverse dependencies. So leaf packages first. >> >> I'm sorry, but I think I need to contest this. Doing things in order, >> first leaf, then go all the way back, will take too long, and this is >> IMO unnecessary effort. > > I maintain tuna, a leaf package. Upstream is working on the py2->py3 > migration. > I expect it to be ready this cycle. I was planning to replace the py2 deps > with > that upstream release. I can release a stripped down (headless) version in > python3 and I'll do that if my package is going to be removed, but I'd rather > wait for upstream's py3 release.
Everyone would like to have better upstream. For OpenStack, swift (the object storage) is still there, without a full Py2 support. I don't want to loose Swift, though if it is removed from Testing for a short time, while upstream finishes to fix things, it's not a big deal, there's always Buster where it can be consumed in the mean time. Do you feel differently for your own package? > Can we set dates for removing packages so maintainers can plan what's > happening? We already have setup dates: right after Buster is released. This was last Saturday. Could you explain why we should delay it more, and how this will be beneficial to the Python 2 removal plan? > I suspect it wouldn't be hard to build a tree from an apt-rdepends graph to > set > up a schedule, guaranteeing all traces of python2 are removed by bullseye and > defining the latest possible removal dates for each package in testing. A constantly updated graph of Python 2 dependencies would definitively be super helpful so we could walk through it in reverse order (as much as possible). This way, we could also know when we're breaking things, and file RC bugs when needed. Thanks a lot for this idea. Though unfortunately, I'm not convinced setting-up deadlines will work, given the way Debian works (ie: you cannot force any contributor to do something). If needed, I can provide the infrastructure (ie: a large VM hosting the graph, directly connected to a Debian mirror at 10 Gbits/s). Though I haven't played much with graphviz to produce such a graph. Does any of us know? What I did so far: debtree -R --rdeps-depth=100 python2.7 >py2.7.deps.dot dot -Tsvg -o py2.7.deps.svg py2.7.deps.dot The result is here: http://py2graph.infomaniak.ch/py2.7.deps.svg How can I get debtree to use Sid instead of Buster (as I'd prefer to keep this VM running Buster)? I could set this VM up and a cron job for how long we need it... Though it looks like I probably have over-sized it. Cheers, Thomas Goirand (zigo)
