Am Samstag, dem 01.01.2022 um 12:14 -0700 schrieb Jesse Gibbons: > > What would be the best way to fix this? > > - keep a mozjs-78.6 package around just for 0ad > > - patch 0ad to fix the compatibility issues with mozjs 78.15 > > - use the mozjs version bundled in the 0ad sources > > > > WDYT? > > Keeping mozjs-78.6 just for 0ad will probably make things harder later > on because it's another package to maintain and users likely won't be > able install 0ad and icecat/icedove in the same profile. I suppose > users can always use `-P /path/to/0ad-profile` when installing or > updating 0ad. I don't think that would be a problem, since mozjs is a regular input. There ought to be no propagation conflicts between the two.
> I'm thinking using the bundled mozjs is perhaps the best option, though > it isn't particularly guixy, because I expect most users would want the > 0ad packaged by guix to be compatible with other 0ad builds in the > wild. There is no benefit to using a bundled version over one packaged with Guix. > Another option would be to keep mozjs-78.6 for 0ad and patch it so > interested users can test updated mozjs using > `--with-input=mozjs=mozjs`. It isn't very difficult to modify a list of > packages to use a specific mozjs in a manifest or home configuration, > right? Though I guess interested contributors could always add the > patch themselves just as easily... Contributors would probably work on top of their local checkouts anyway, so there's no concern here (other than increased store space for another mozjs both locally for users and in CI). @Guillaume: From what I can gather from the build error, it appears as though the calling convention changed to require an additional parameter. I've tracked down the relevant commit [1] and bug [2]. Now obviously doing such a thing violates SemVer, so if rewriting 0ad with this and other changes in mind is not an option, I think having a hidden package for 0ad might be the lesser evil. Cheers [1] https://searchfox.org/mozilla-central/commit/a3c605929b16303e8a52ae9d99d5fe6769e8bf09 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1681268
