Bug#1094440: transition: xnnpack and onednn for PyTorch 2.6
Hi Paul and Emilio (again),
> -----Original Message-----
> From: Shengqi Chen <harry@debian.org>
> 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
Reply to: