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

[Markus Koschany]

Hello,

Am Donnerstag, dem 06.04.2023 um 12:54 +0200 schrieb Paul Gevers:
> Hi,
> 
> On Sun, 26 Mar 2023 16:26:00 +0200 Markus Koschany <apo at 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).

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. But there is always a risk
whenever you change something. Remember why we did the upgrade in the first
place. We did fix two RC bugs and just hit a special case with a leaf package
(shrinksafe)

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."

We can do a binNMU for all reverse-dependencies but I do not think it is
necessary.

> 
> 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. 

> 
> > 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.


> > 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).

The solution is to tighten the dependency on rhino and adjust the autopkgtest
accordingly. 

> > 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).

As I said this is standard procedure for Java libraries which I touch. It does
not imply a transition is needed.

> > 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.
[...]
> 



> 
> 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!


Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20230406/9b08f0f4/attachment.sig>