Hi,
> -----Original Message-----
> From: Paul Gevers <elb...@debian.org>
> Sent: Thursday, February 20, 2025 3:10 PM>
>
> Yes, but what depends on how bad those failures are for real users that
> would do a partial upgrade. As the test times out without any useful
> output, I can't see what's going on except that apparently the test
> hangs in a loop. Would that be representative of what a user of
> pytorch-{scatter,sparse} would experience if they updated everything
> except pytorch-{scatter,sparse} (which is allowed by the package
> inter-dependencies), or maybe only installed libtorch2.6. I'll note that
> officially we still don't support partial upgrades, but we are getting
> better and better at it. So it's worth spending a minute on.
The cause is these old pytorch-foo packages depend on libtorch2.5,
while new pytorch uses libtorch2.6. So this is causing both libraries to be
dlopen-ed when pytorch-foo tries to import torch in Python, and this is
obviously broken.
And for the symptoms -- when I try personally, libtorch would throw an
exception which leads to SIGABRT. The arm64 autopkgtest shows the similar
output [1]. As for amd64, it would also abort and stuck in an unknown state,
and maybe this explains the timeout on debci.
At this moment I don't see any elegant solution to this, users would have to
upgrade everything to avoid the breakage. Do you have any suggestions?
[1]: https://ci.debian.net/packages/p/pytorch-scatter/testing/arm64/58020689/
--
Thanks,
Shengqi Chen
