Hi, On Sun, 26 Mar 2023 16:26:00 +0200 Markus Koschany <a...@debian.org> wrote:
1. There is no transition needed because only shrinksafe is affected by the new rhino version.
I'm wondering how you know, did you test (without rebuilding) all the reverse dependencies? If so, how did you do that? (I'm worried we're missing cases like src:dojo).
Also, given that shrinksafe is from a different source than rhino, this qualifies as a transition (it *needs* changes in different (binary) packages).
2. shrinksafe has no reverse-dependencies
So it can be easily removed, but that's not a great service to its users.
3. We had the exact same problem before [1]. Back then the fix was to rebuild the package and to fix the shrinksafe tests by setting a specific Javascript version. [2] Since just rebuilding dojo also fixes the problem, I assume that we don't have to change this option.
Well, rebuilding without fixing the underlying issue is just papering over. I'd like to get a proper (future proof) solution in place, see below. (And yes, we can paper over for bookworm now).
4. I have rebuilt all rhino reverse-dependencies successfully.
Yes, normal transitions are handled that way, we (the Release Team) schedule binNMU's for those (albeit we can't do arch:all that way).
6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable. Hence why I tightened the dependency on rhino to 1.7.14. The current version of rhino in testing breaks the Javascript application.
Suggesting even more that this is a real transition.
7. Summary: I recommend to rebuild dojo to fix the autopkgtests. I suggest to reconsider the current autopkgtest behavior. At least there should be a warning or a note for maintainers in the future that dojo requires a rebuild whenever rhino changes.
In Debian we normally handle that by either real or virtual abi packages (although in your other message you mention you didn't know of the breakage, so I guess that wouldn't have helped in this particular case, but it would have given you the knob to fix it after the discovery of the breakage). We have a huge collection of examples in Debian for that. If rhino (the binary) were to Provides an abi, than dojo could Depends on that (with the right version inserted during the build). The Release Team tooling [1] would then pick up when the ABI is bumped such that binNMU's can be scheduled (or the appropriate people can be notified in case of arch:all).
I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5 today, where I'll add an appropriate Breaks to src:rhino and an appropriate versioned Depends to src:dojo. Please let me know if you object or want to handle this yourself.
Normally we would defer the new upstream version and transition at this stage of the release, but I want rhino to migrate to bookworm.
Paul [1] https://release.debian.org/transitions/
OpenPGP_signature
Description: OpenPGP digital signature
