Hi Markus, Thanks for following-up. It further clarified pieces.
On 06-04-2023 15:14, Markus Koschany wrote:
I always rebuild all reverse-dependencies with ratt before I upload a Java library package. From my Java experience I know this uncovers almost all problems. Rhino is not some obscure C/C++ library. It is a Javascript engine written in Java. You can install reverse-dependencies and run them against the new rhino version. If the package works, then there is no further action required. Could I have missed a corner case? Maybe.
If you believe it to be a corner case (that you elaborate on later on), then I trust you on that. The corner case just looked like a transition from our side (Release Team) of the story.
From dojo developer documentation: "Note that the linkage requires the same version of Rhino used to build the shrinksafe.jar. In versions prior to Dojo 1.3, ShrinkSafe was bundled into Rhino by way of patch, and shipped as custom_rhino.jar."
Thanks for that piece of info.
We can do a binNMU for all reverse-dependencies but I do not think it is necessary.
Good to know, I wasn't particularly liking the idea.
Also, given that shrinksafe is from a different source than rhino, this qualifies as a transition (it *needs* changes in different (binary) packages).I cannot remember when we asked for a Java library transition in the past. shrinksafe is, as I pointed out before, a special case. It was once part of the rhino distribution and probably should have tightened the dependency on a specific rhino version in the first place.
Ok, let's have the dojo maintainers tighten the relation then in their next upload.
2. shrinksafe has no reverse-dependenciesSo it can be easily removed, but that's not a great service to its users.No, we don't want to remove neither shrinksafe nor any other package. Please don't exaggerate the problem at hand.
Well, autoremoval was about to do that in a few days if nobody intervened.
The solution is to tighten the dependency on rhino and adjust the autopkgtest accordingly.
If the dependency is tightened, autopkgtest will do the right thing.
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.You are misunderstanding the problem. OpenRefine does not work with Rhino in testing. The new rhino in unstable fixes the problem. Again, rhino 1.7.14 is the solution, not the cause of the problem. [...]
Yes, I typed this before I had further insights and forgot to review this piece. Indeed, you're right.
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.Fine with me and thanks!
I'll also reschedule rhino then. Thanks for your help and contributions for bookworm. Paul
OpenPGP_signature
Description: OpenPGP digital signature
-- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
