[陈 晟祺] > Certainly true. But let me explain the situation more: > xnnpack currently does not have a symbol control file, and had only > one reverse dependency pytorch until the recent upload of onnxruntime.
Why does it not have a symbol control file? Is there any hope to reach upstream proper shared library practice? > I was working on bumping pytorch's dependencies recently, without > noticing it having onnxruntime as rdep. And that's why I did not check > through the symbol changes and uploaded a breaking version. Perhaps this would become easier with a symbol control file? > Since pytorch 2.4 is now in sid, the only broken package is > onnxruntime. It is the only broken package in the Debian archive, but there might be billions of software systems built locally on users machine which are also broken. Proper SONAME handling would reduce the problem. > I have just packaged a new version of ort (see: 1080510) which can be > used with latest xnnpack in sid. Rebuilding and uploading a new onnxruntime make sense, but is not really addressing this problem, which is incorrect handling of a shared library. Forcing unexpecting users to rebuild their software is not a good approach. -- Happy hacking Petter Reinholdtsen
