= 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
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
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."
ping?
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.