Hi Paul and Emilio (again), > -----Original Message----- > From: Shengqi Chen <[email protected]> > Sent: Thursday, February 20, 2025 10:23 PM > > > (Emilio) > > Britney schedules the pytorch tests against rdeps in testing, to ensure they > > don't break, as pytorch could migrate before and independently of its rdeps. >> If > > the tests break that way, and it's a test-only thing, we could ignore it. > > If the > > rdeps actually break, then perhaps pytorch should gain Breaks against the > old > > rdep versions. Then the autopkgtests will be scheduled properly. > > > > (Paul) > > Maybe not elegant per se, but it would be correct: add a versioned > > Breaks to pytorch to the versions in testing that it breaks. Then the > > migration software will also be able to schedule the tests with the > > right things from unstable (I think. But while I'm thinking about it, > > I'm not 100% sure if it handles the binNMU'd case correctly). > > Thank you both for explaining! I would add the corresponding Breaks to > pytorch.
In pytorch 2.6.0+dfsg-2, @lumin add Breaks: libtorch2.5 to libtorch2.6. We did this to avoid any potential simultaneous use of these two libraries. However, it seems Britney don't pick up binNMU versions, leading to uninstallable dependency issues [1][2][3] in migration reference tests. So maybe I should do no-op source-only uploads for them to mitigate? [1]: https://ci.debian.net/packages/p/pytorch-cluster/testing/amd64/58047373/ [2]: https://ci.debian.net/packages/p/pytorch-scatter/testing/amd64/58047375/ [3]: https://ci.debian.net/packages/p/pytorch-sparse/testing/amd64/58047376/ -- Thanks, Shengqi Chen
