Talk:JavaScript libraries packaging guideline draft

Packages

• I've submitted a jsmin package for review as: https://bugzilla.redhat.com/show_bug.cgi?id=455507 --dmalcolm 2008-07-21
  • This will help us to compress javascript files from within Fedora. --abadger1999 00:48, 11 August 2008 (UTC)

• I've submitted jquery: https://bugzilla.redhat.com/show_bug.cgi?id=457343 --abadger1999 00:48, 11 August 2008 (UTC)

Issues

Inconsistency for apache .conf file

The MUST section of the guideline requires Apache configuration files to go in %{_sysconfdir}/js/, while the file system locations component instructs that they go into %{_sysconfdir}/httpd/js.d. The 'model' spec file (MochiKit) head fakes towards %{_sysconfdir}/http/js.d, but then puts files into %{_sysconfdir}/js.d. However, the current (as of 2003-02-15) MochiKit .spec file places that file directly into %{_sysconfdir}/httpd/conf.d. I suspect that this should all be changed to match what MochiKit currently does, but at the least, the inconsistencies should be removed.

mootools

mootools is much better now; there are direct download links for the "enchilada" builds, but projects are still encouraged to use the customizer to build just what they need. In many ways this makes sense, because these files may be sent to millions of clients, but it doesn't get along with general packaging.

One possibility would simply be to carry a couple of customized versions as needed by other packages if there's actually a real space savings. --Tibbs 00:11, 10 August 2008 (UTC)

I don't like having multiple versions but I can't think of a ready alternative. There are javascript frameworks to specify a set of javascript files that you need and while developing they are separate files but when you deploy they are made into a single compressed file transparent to your code. Maybe in the future someone who cares can look into tying this into a dynamic program of some sort. Not for us to do now, though. --abadger1999 00:48, 11 August 2008 (UTC)

Naming

• Do we need a naming standard for various compressed versions? --Tibbs 00:11, 10 August 2008 (UTC)
  • Definitely. Should we just make up extensions as we add "compressed" versions? MAINFILE-COMPRESSIONMETHOD.js. ex: jquery.js => jquery-min.js This means that we'd have to have some registry of compression methods. --abadger1999 00:48, 11 August 2008 (UTC)

• If multiple versions (say, of mootools with different modules enabled), do we need a naming standard for that? --Tibbs 00:11, 10 August 2008 (UTC)
  • This one's harder. Does upstream have a name for these or is everything just "mootools.js"? --abadger1999 00:48, 11 August 2008 (UTC)

• Do we need a naming prefix like perl, python, etc? javascript-jquery, for instance. --abadger1999 00:48, 11 August 2008 (UTC)

Compression

• Do we need to generate the compressed versions ourselves, or is it permissible to get them from upstream? --Tibbs 00:11, 10 August 2008 (UTC)
  • I vote that we have to do it ourselves. it's not immediately discernable what the code is doing once it's been compressed so it's better to treat it as non-source at that point. --abadger1999 00:48, 11 August 2008 (UTC)
• The guideline currently says that the uncompiled version must be provided alongside the compiled version. Couldn't the uncompiled version just be in the source package, like with other Fedora packages? Mattmccutchen 16:41, 13 December 2010 (UTC)

Versioning

• I think it's obvious that we'll soon run into the problem of different packages needing different javascript library versions, since upstreams expect packages to simply code to the version that they copied. Should we consider having multiple upstream versions in one package as necessary, or would we force them to be in different packages? --Tibbs 00:11, 10 August 2008 (UTC)
  • Do we want to encourage multi-versioning? Having multiple versions means if we have a security issue, we end up having to look for and patch the problems in all versions instead of letting upstream do the work on their trunk and then shipping the latest version. I think we want to get upstreams to be better about tracking the latest versions of the javascript libraries just like we try to port code to newer versions of C libraries.... Since this is going to have short term pain, we should allow multiple versions but not make it easy. --abadger1999 00:48, 11 August 2008 (UTC)

• When we have to have separate versions, I'd put them into separate subdirectories ie: jquery-1.2/jquery.js jquery-1.3/jquery.js --abadger1999 00:48, 11 August 2008 (UTC)

Symlinking

• Also, some projects like zoneminder actually want to see the javascript files located in their web space. Should it be permissible to symlink to the files as necessary instead of coding things such that clients are diverted to the specific /js web space for those files? --Tibbs 00:11, 10 August 2008 (UTC)
  • I think symlinks are fine at this point. If the idea of putting javascript into specific places catches on with other distros this might be something to reconsider. --abadger1999 00:48, 11 August 2008 (UTC)

Plugins

• While packaging jquery I realized that some frameworks have lots of plugins. This guideline implies that those plugins will need to be put in separate packages. I think this is good as the licensing and security considerations are still there but it is a source of inefficiency since we'll have a lot of spec files that do nothing but:

 install -p %{SOURCE0} %{_datadir}/jquery/plugins/jscalendar.js}}}

--abadger1999 00:48, 11 August 2008 (UTC)

• It can be one spec file generating multiple rpms. Of course you could group the modules into one subpackage, or if it is not too many, do it per module like %package jscalendar so that it results in jquery-jscalendar.rpm

--Mrmichaelwill 17:26, 23 June 2009 (UTC)

• • One SRPM => multiple RPMS would only have one advantage over putting all plugins into a single RPM. They would be installable separately. The other disadvantages of this approach over 1 tarball => 1 RPM remain. Licensing can still be different between the tarballs that people dealing with the source would have to understand. An update to a single plugin would force rebuilds/updates for all of the plugins.

--abadger1999 21:08, 23 June 2009 (UTC)