[Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Paul Gevers]

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-dependencies
>>
>> So 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20230406/20a73695/attachment.sig>