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

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

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/
-------------- 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/af48c4de/attachment.sig>