On 06/06/2009 08:27 PM, King InuYasha wrote: > Dan, the developer of Enano CMS, which I am packaging, has said that if > you guys and myself can identify all the places a 3rd party bundled > library worthy of being separated is, he will add the APIs necessary to > support linking out to 3rd party code in separate packages outside of > Enano root. > Excellent! > With two exceptions: TinyMCE and > jQuery. Since both are javascript libraries, they cannot have "security" updates. > The claim that JavaScript libraries are immune to security flaws is untrue. Furthermore, they are also subject to the licensing problems that I mentioned as the second reason we do not bundle libraries in the Enano ticket. However, JavaScript libraries bundled with web frameworks is currently allowed until we work out how the JavaScript libraries should be packaged. I'm currently leaning towards using static linking as the model for JavaScript packaging but I don't know if it will pass muster or not. Basically, JavaScript, like other scripting languages, can be "dynamically linked" by referring to a URL for the JavaScript library in a web page. The original draft of the JavaScript Guidelines defined URLs where the libraries would reside on the server and therefore where they could be referenced from. (You can see that draft here: http://fedoraproject.org/wiki/PackagingDrafts/JavaScript ) However, JavaScript libraries are different from PHP, python, perl, etc, in that they are files that are installed on the server running Fedora but delivered and executed on a client via an http connection. Because of this, optimizations to make smaller files and more efficient use of http can have an impact on the perceived performance of the web application. So I'm working on a new draft that takes into account "compiling" a JavaScript file (Basically, combining multiple files together and compressing the result.) Since the optimal way to do this is to combine all the files that are needed for a page (or multiple pages of an application), the combined file is very likely to be specific to the application. This seems close to static linking functions from libraries together with some application code to make a program so the rules for keeping that sane within Fedora seem to make sense as a model for what to do here. Among other things this would mean: * We would link against the system installed version of the library, not the bundled copy. * The application could continue to use the same location for the library but the library would have to be copied to that location from the system version, not from any bundled version. * Packagers would be required to add themselves to the CC list of the JavaScript libraries they depend on so that they are made aware of new releases and can rebuild their packages to pick up the changes. If people like or dislike using static linking as the model, please send in your comments. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
