#27 Permission for oolite to bundle the SpiderMonkey js library
Closed: Invalid None Opened 13 years ago by salimma.

= Proposal topic =

Allow bundled js library for oolite

= Overview =

oolite, a space simulation game, bundles a copy of js. There are several
main reasons:
1. the system copy was, for a long time, not compiled with UTF8 support.
It probably still is not
on many other distributions
https://bugzilla.redhat.com/show_bug.cgi?id=459211#c13

  1. our js is compiled with THREADSAFE support. upstream claims that the
    API is significantly
    changed, and that the performance hit is non-negligible.
    https://bugzilla.redhat.com/show_bug.cgi?id=459211#c34

  2. as the library is only used with local scripts, upstream thinks there
    are no security risks
    https://bugzilla.redhat.com/show_bug.cgi?id=459211#c16

A more detailed overview of the proposal

= Problem space =

Getting oolite packaged in Fedora; as a non-trivial large GNUstep
application this helps making sure that the GNUstep stack is in decent
condition

= Solution Overview =

If permission is granted to bundle js, there is no problem. I've marked
the spec with a virtual provides for bundled(js) = 1.70.

If not, then either we convince upstream to use the thread-safe system js,
patch oolite ourselves to make that works, or drop the package.

= Owners =

Michel Alexandre Salim
FAS: salimma / IRC: hircus


Looks like:
1. is solved in Fedora
2. is better solved by first seeing if our spidermonkey maintainer would be willing to produce a version of libjs without THREADSAFE.
3. I really don't agree with. Yes, the game packs would be loaded locally but unless only the user themselves is writing gamepacks, the user is still loading data that comes from an external source.

If you still want to pursue bundling, FPC has the standard questions: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions which should be answered to see if there's some reason we should grant an exception. At the moment, I don't think we would until we know the answer to #2 above.

In discussion on IRC, walters mentioned that upstream doesn't really test the nonthreaded build and that it may go away:

[Thursday 11 November 2010] [11:06:46] <walters> tibbs: i don't think upstream really tests non-JS_THREADSAFE builds really
[Thursday 11 November 2010] [11:06:52] <walters> it seems likely to go away
[Thursday 11 November 2010] [11:06:58] <tibbs> Lovely.
[Thursday 11 November 2010] [11:07:01] * walters speaks from experience, note

This would imply (assuming it's correct) that modifying our js package to produce both threaded and nonthreaded builds may not work out in the long term, and anything absolutely requiring the nonthreaded build would have to bundle it in perpetuity.

I think that it would be useful to know how different the threaded API really is, and how significant the performance difference is. Because the performance argument without any numbers sounds a while lot like "my code builds with -O9 for MAXIMUM SPEED."

The Fedora Packaging Committee has denied this exception request, and recommend you patch oolite to use the system js, and only if that is determined to be impractical/impossible, reopen this request for reconsideration.

Vote (to deny exception): (+1:6, 0:0, -1:0)

Login to comment on this ticket.

Metadata