Dear release team, I feel the case I encountered is an unusual transition, so I'd like to ask first before filing the bug.
Long story short, src:luajit does not work on ppc64el because the upstream is completely not interested in supporing IBM archs https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011297 So I uploaded luajit2, which at least passed hello world smoke test on IBM arches including ppc64el and s390x. https://buildd.debian.org/status/package.php?p=luajit2 Currently, src:luajit2 produces bin:luajit2, which Conflicts+Replaces bin:luajit. Meanwhile there is bin:libluajit2-5.1-2, which Conflicts +Replaces bin:libluajit-5.1-2 from original src:luajit. luajit and luajit2 are expected to be compatible in binary level. So I changed the dependency template for bin:libluajit-5.1-2 from libluajit-5.1-2 into libluajit-5.1-2 | libluajit2-5.1-2 Since both packages Provides libluajit-5.1.so.* Thus, this is not a usual transition with ABI bump. I want to rebuild all luajit reverse dependencies so that the dependency template for them will be updated. In that case the corresponding reverse dependencies can smoothly start to use libluajit2-5.1-2, especially for ppc64el architecture. When the rebuild is done, we should be able to safely remove ppc64el architecture for src:luajit . I did not change the dependency template for libluajit2-5.1-2, because it supports a wider range of architectures than the original version. Once compiled against src:luajit2, I don't hope a package fallback to use original src:luajit and crash. May I ask some suggestions on the correct way to handle such a special transition? And it is complicated as a ppc64el RC bug is involved https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011297
