Bug 457343

Good:
* Source URL is canonical
* Upstream source tarball verified against svn
* Group Tag is from the official list
* Valid license tag
* Buildroot has all required elements
* All paths begin with macros
* All directories are owned by this or other packages
* All necessary BuildRequires listed.
* All desired features are enabled
* Files have appropriate permissions and owners
* rpmlint produces no errors
* Package installs and uninstalls cleanly.
* Spec has good comments explaining patches and other building issues.
* Package builds fine in Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=769554

Looks pretty good, but I'll hold off on giving a final approval until the javascript guidelines are finished for outstanding issues (versioning, etc).

It seems as though no efforts have been made on this for over two years and two months. This review appears to be abandoned or forgotten. I would very much like to maintain the jquery package. I have rewritten the jquery spec using an existing working model MochiKit. Please, allow me to resubmit the jquery package for review. Can someone give me a hint as to if this is possible and how I can regain review submission for this package?

Spec URL: http://aikiframework.org/files/jquery/jquery.spec
SRPM URL: http://aikiframework.org/files/jquery/jquery-1.4.4-1.fc13.src.rpm

Description:
jQuery is a new type of JavaScript library.

jQuery is a fast, concise, JavaScript Library that simplifies how you traverse
HTML documents, handle events, perform animations, and add Ajax interactions
to your web pages. jQuery is designed to change the way that you write
JavaScript.

If possible, this would be my third package review submission to Fedora and I need a sponsor. I set the jquery package to require the sizzle package which can be seen here https://bugzilla.redhat.com/show_bug.cgi?id=654151.

Ran successful rpmlint on spec, srpm and rpm
$ rpmlint SPECS/jquery.spec \
SRPMS/jquery-1.4.4-1.fc13.src.rpm \
RPMS/noarch/jquery-1.4.4-1.fc13.noarch.rpm 
2 packages and 1 specfiles checked; 0 errors, 0 warnings.

Ran successful mock rebuild
$ mock --rebuild SRPMS/jquery-1.4.4-1.fc13.src.rpm 
INFO: mock.py version 1.1.6 starting...
State Changed: init plugins
INFO: selinux disabled
State Changed: start
INFO: Start(SRPMS/jquery-1.4.4-1.fc13.src.rpm)  Config(fedora-13-i386)
State Changed: lock buildroot
State Changed: clean
INFO: chroot (/var/lib/mock/fedora-13-i386) unlocked and deleted
State Changed: init
State Changed: lock buildroot
Mock Version: 1.1.6
INFO: Mock Version: 1.1.6
INFO: enabled root cache
State Changed: unpacking root cache
INFO: enabled yum cache
State Changed: cleaning yum metadata
INFO: enabled ccache
State Changed: running yum
State Changed: setup
State Changed: build
INFO: Done(SRPMS/jquery-1.4.4-1.fc13.src.rpm) Config(default) 0 minutes 26 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-13-i386/result

Ran successful koji scratch builds
https://koji.fedoraproject.org/koji/tasks?owner=fosdevel&state=all
$ koji build --scratch dist-f13 jquery-1.4.4-1.fc13.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=2605788
$ koji build --scratch dist-f13-kde jquery-1.4.4-1.fc13.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=2605777
$ koji build --scratch dist-f13-updates-candidate jquery-1.4.4-1.fc13.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=2605785
$ koji build --scratch dist-f14 jquery-1.4.4-1.fc13.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=2605775
$ koji build --scratch dist-f14-gobject jquery-1.4.4-1.fc13.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=2605780
$ koji build --scratch dist-f14-kde jquery-1.4.4-1.fc13.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=2605774
$ koji build --scratch dist-f14-updates-candidate jquery-1.4.4-1.fc13.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=2605783
$ koji build --scratch dist-f15 jquery-1.4.4-1.fc13.src.rpm
http://koji.fedoraproject.org/koji/taskinfo?taskID=2605782

A JavaScript library similar in packaging was approved and has
existed in Fedora for quite a while. The name of the package is MochiKit which
can be seen here http://pkgs.fedoraproject.org/gitweb/?p=MochiKit.git;a=tree.
Here is a link to the approved review
https://bugzilla.redhat.com/show_bug.cgi?id=176528.

Using rpmlint update as specified here:
https://fedoraproject.org/wiki/Packaging/Guidelines#Use_rpmlint

Ran successful rpmlint on spec, srpm, rpm and installed rpm
$ rpmlint jquery \
SPECS/jquery.spec \
SRPMS/jquery-1.4.4-1.fc13.src.rpm \
RPMS/noarch/jquery-1.4.4-1.fc13.noarch.rpm
3 packages and 1 specfiles checked; 0 errors, 0 warnings.

it seems like a very good idea to properly package jquery as a huge number of packages seems to bundle it. Check the output of 'yum whatprovides */jquery-*.js'.

Hey Steven, going to what MochiKit does is probably a step backwards from what is posted in my last package.  I was doing this package while working on the JavaScript Guidelines and during that process we basically started with what MochiKit did and made improvements from there.

This basically stalled because I wanted to get the Packaging Guidelines for JavaScript working but got lost in technical issues with it for a while.  Here's the draft documentation:
https://fedoraproject.org/wiki/JavaScript_libraries_packaging_guideline_draft

If you'd like to work on the draft a lot of people would be very pleased!  The things that came up when the FPC discussed it were:

1) We should make a distinction between JavaScript intended to be served to browsers and JavaScript which can be run on the local machine.  For instance, KDE now has javascript bindings.  The JavaScript on local machines may have tougher security considerations than JavaScript run on browsers.  It should probably go in different directories than the browser-libraries, etc.

2) Over time I've come to believe that a static linking model is more appropriate than a dynamic linking model for browser based JavaScript.  As an example, an application needing jquery would use the code in this package when it builds but it would be free to copy the jquery from this package into itself.  When this jquery package updates, the web application would need to be ported to the new version of jquery at that time.  Provides and Requires similar to that used for static linking would be used to track what libraries at what versions are being statically linked.

3) We need to anticipate handling of multiple versions of a library.  For many years, we're going to find that different applications work with different upstream versions of a javascript library.  Only after we've been packaging for a time will it become normal for upstreams to port to newer versions of the JavaScript libraries as they come out just like they port to newer versions of their server-language's libraries.

What's the status? I would like to depend on it in one of my packages :)

Would you like to take over?  I'm not using jquery myself and the draft has stalled (for years).

I would like to take over if I can figure out how to solve the Sizzle "problem" and some other issues....

I'm not a huge fan of requiring a modification to all software that depends on jquery.js to now all of a sudden also require an extra <script> tag to import sizzle.js (as suggested by Steven) and possibly break compatibility (update sizzle while not updating jquery, or the other way around). Just changing the path to the jquery JS file seems a little bit more reasonable...

2) The static linking idea is interesting, but I guess we then might as well just leave the "original" bundled jquery in the package to be sure it works as the developers intended.

3) Maybe somehow all versions can be made available in the package?

- The jquery package can just contain the minified versions of all jquery versions ever released (like what is available on the Google CDN)? 
- Or maybe have two packages. The jquery package (containing only the latest version) and a compat-jquery package (containing all? the previous versions)?
- Or implement a CDN api like Google for JS containing all jquery (and other js libs) versions?

4) It would be interesting to pull jquery from git and build it locally (using the Makefile). This pulls in Sizzle and Qunit from git. Possibly something can be done there to unbundle? Furthermore it would require nodejs (not packaged yet?) to minify jquery...

5) It seems to be impossible to test all software after upgrading jquery to a newer version (see jquery 1.6.1 .attr() problem for instance). Should there be test procedures? updates-testing is time enough for package maintainers/users to check software against the latest version of jquery? How to avoid negative karma if stuff breaks? :)

6) How to fix all local copies of jquery in packages from being used? Use a (Apache) rewrite rule that redirects all */jquery*.js calls to /js/jquery.js? :-)

(In reply to comment #8)
> I would like to take over if I can figure out how to solve the Sizzle "problem"

Like I say, I'm not using jquery now so I don't know the extent of the sizzle problem.  Does jquery actually require sizzle?  Is it something that gets included into jquery when jquery is "built"?  Need more information here....
> 
> 2) The static linking idea is interesting, but I guess we then might as well
> just leave the "original" bundled jquery in the package to be sure it works as
> the developers intended.
> 
What "static linking" adds is the ability to track what libraries (and depending on the actual deps that we use, also their versions) are being used by an application.  That way if foo was using jquery-1.0 and jquery-1.1 is released that fixes an issue (security, major bugfix, change to a more permissive license, etc) found in jquery-1.0 we'd know what software was using the old jquery and be able to rebuild them with the new version.

> 3) Maybe somehow all versions can be made available in the package?
> 
> - The jquery package can just contain the minified versions of all jquery
> versions ever released (like what is available on the Google CDN)? 

It would probably be good to have both minified and "source" versions installed.  GPL compliance would make this a requirement for some libraries... (possibly if it was the app was GPL although I'm very unclear on this.)

> - Or maybe have two packages. The jquery package (containing only the latest
> version) and a compat-jquery package (containing all? the previous versions)?
> - Or implement a CDN api like Google for JS containing all jquery (and other js
> libs) versions?
> 
Yeah -- I think we should have multiple packages.  whether that's one for the current version and one for all older versions or one for each older version I'm not sure.  And how to set those up internally I'm not sure.

> 4) It would be interesting to pull jquery from git and build it locally (using
> the Makefile). This pulls in Sizzle and Qunit from git. Possibly something can
> be done there to unbundle? Furthermore it would require nodejs (not packaged
> yet?) to minify jquery...
> 
Hmm... If jquery is being shipped minified, we'd have to create that minified version from the source version no matter what.

nodejs was under review but Lubomir seems to have disappeared:
https://bugzilla.redhat.com/show_bug.cgi?id=634911


> 5) It seems to be impossible to test all software after upgrading jquery to a
> newer version (see jquery 1.6.1 .attr() problem for instance). Should there be
> test procedures? updates-testing is time enough for package maintainers/users
> to check software against the latest version of jquery? How to avoid negative
> karma if stuff breaks? :)
> 
I don't see us being more strict than with other libraries from other languages.  So, probably, be conservative in upgrading the library in older releases.  Use updates-testing.  Check software as best we can, etc, etc.

> 6) How to fix all local copies of jquery in packages from being used? Use a
> (Apache) rewrite rule that redirects all */jquery*.js calls to /js/jquery.js?
> :-)

Review and fix.  Someone could check for files named jquery in the yum repository repodata to generate that list.  This would be something to do after/if guidelines specifying how to package javascript libraries are approved.

> Like I say, I'm not using jquery now so I don't know the extent of the sizzle
> problem.  Does jquery actually require sizzle?  Is it something that gets
> included into jquery when jquery is "built"?  Need more information here....

Yeah, it gets included during "build". It can be extracted (i.e.: not included during building with some Makefile modifications), but I guess you need to then include "js/sizzle.js" before including "js/jquery.js" in your application. Would that be an acceptable requirement for packagers?

> What "static linking" adds is the ability to track what libraries (and
> depending on the actual deps that we use, also their versions) are being used
> by an application.  That way if foo was using jquery-1.0 and jquery-1.1 is
> released that fixes an issue (security, major bugfix, change to a more
> permissive license, etc) found in jquery-1.0 we'd know what software was using
> the old jquery and be able to rebuild them with the new version.

Above you suggested to copy the jquery.js in the package itself. Would requiring a specific version of jquery (the one currently available in the distro you are packaging for) already be enough? So in the spec you can say:

   Requires: jquery = 1.6.2

That will take care of screaming when the jquery package gets updated and force the application packager to take action... Annoying if there is a new version every month...

> It would probably be good to have both minified and "source" versions
> installed.  GPL compliance would make this a requirement for some libraries...
> (possibly if it was the app was GPL although I'm very unclear on this.)

Yep, that was the intention anyway...

> Yeah -- I think we should have multiple packages.  whether that's one for the
> current version and one for all older versions or one for each older version
> I'm not sure.  And how to set those up internally I'm not sure.

That is a big issue, not sure a correct answer exists. I saw Debian ships quite a few js libs, including jquery named libjs-jquery. It seems they just have one version and keep that for the life of the distro... That would also be an option, only upgrade the package in rawhide and never upgrade the released distro after it is released. I'm not sure in the case of jquery there are any security updates to old versions of jquery anyway...

> Hmm... If jquery is being shipped minified, we'd have to create that minified
> version from the source version no matter what.

It ships both minified and unminified. But I guess if we want to provide the minified version as well we need to "translate" it ourselves.

> nodejs was under review but Lubomir seems to have disappeared:
> https://bugzilla.redhat.com/show_bug.cgi?id=634911

Added this bug to depend on 634911.

While this is surely a more general problem, I just happened upon this and this:

> but I guess you need to then include "js/sizzle.js" before including
> "js/jquery.js" in your application. Would that be an acceptable requirement
> for packagers?

most certainly is not going to fly in the real world. Are you really suggesting that every webapp needs to be patched by packagers to do this? Because upstreams will certainly refuse such a patch anyway...

If this package makes it through and it *requires* modifications to packaged webapps to make use of it, I would not be surprised if the number of packaged webapps simply drops (but hey, please prove me wrong).

IMHO, comparing a javascript "library" to a .so is simply wrong to begin with, and bundling here should be allowed. The only thing to make sure is that security issues can be identified ASAP; which involves making it easy to identify every .srpm that bundles a specific jquery version.

(In reply to comment #10)
> Yeah, it[sizzle] gets included during "build". It can be extracted (i.e.: not included
> during building with some Makefile modifications), but I guess you need to then
> include "js/sizzle.js" before including "js/jquery.js" in your application.
> Would that be an acceptable requirement for packagers?
> 
Under the idea of making javascript libraries more like static libraries, jquery would be able BuildRequire: the sizzle javscript library.  As part of its build, jquery would substitute this system version of sizzle for the one that it bundles in its tarball.  Then it would build with that.  Applications that depend on jquery would continue to just include jquery.js as the jquery that we built for the rpm would have the system sizzle included inside of it.

> 
> Above you suggested to copy the jquery.js in the package itself. Would
> requiring a specific version of jquery (the one currently available in the
> distro you are packaging for) already be enough? So in the spec you can say:
> 
>    Requires: jquery = 1.6.2
> 
> That will take care of screaming when the jquery package gets updated and force
> the application packager to take action... Annoying if there is a new version
> every month...
> 
Yeah... So this would have a more immediate and noticable affect on the packages being shipped.  I'm not sure that that's a good or bad thing.  On the plus side, the packagers must do something about it or else applications won't be able to update jquery, users will file bugs, etc.

On the negative side, this prevents installing updating jquery and possibly other things (if the user doesn't know to use yum --skip-broken).

I lean towards the static library idea as it becomes a buildtime problem that's less visible to end users but I can see the pros and cons of either option.

> > Yeah -- I think we should have multiple packages.  whether that's one for the
> > current version and one for all older versions or one for each older version
> > I'm not sure.  And how to set those up internally I'm not sure.
> 
> That is a big issue, not sure a correct answer exists. I saw Debian ships quite
> a few js libs, including jquery named libjs-jquery. It seems they just have one
> version and keep that for the life of the distro... That would also be an
> option, only upgrade the package in rawhide and never upgrade the released
> distro after it is released. I'm not sure in the case of jquery there are any
> security updates to old versions of jquery anyway...
> 
yeah -- just like with any other library, we can either be proactive about these things and try to get the distro, as shipped on release-day standardized on a single version of the library to make fixing things like this easier, or we can let several parallel versions of the library exist and then work like mad if we need to do a backport of a security fix in the middle of the release.

> > Hmm... If jquery is being shipped minified, we'd have to create that minified
> > version from the source version no matter what.
> 
> It ships both minified and unminified. But I guess if we want to provide the
> minified version as well we need to "translate" it ourselves.
> 
Yep.

(In reply to comment #11)

> IMHO, comparing a javascript "library" to a .so is simply wrong to begin with,
> and bundling here should be allowed. The only thing to make sure is that
> security issues can be identified ASAP; which involves making it easy to
> identify every .srpm that bundles a specific jquery version.

Simply identifying is not enough.  We must also be able to fix and to deploy the fix.  Treating the javascript library the same as an .so makes that whole chain the easiest.  However, I've already stated that I don't think we can manage that at the moment and proposed treating javascript libraries as static libraries (.a) as a better compromise.  Treating as a .a allows identifying because you can query the buildrequires of packages to determine what packages have linked to jquery.  It makes fixing slightly easier because you can know that the jquery shipped with an app previously does not have local, app-only modifications.  It does not go further to protect us from having to port a lot of packages to newer APIs at crunch time (in the days or hours before a vulnerability is publically announced), having to rebuild all affected packages, or allow us to deploy a single, fixed version of the library package instead of having to distribute the fixed library and all of the applications that have been rebuilt with the fixed version.

I wrote a jquery package the other day for an app of mine. My app does not serve anything to the web, so my package does not make any assumptions of web server and whatnot.

https://bugzilla.redhat.com/show_bug.cgi?id=805587

I'm not going to maintain this package so I'm going to close it duplicate of Luke's.  Still some things to work out like how to unbundle sizzle but still provide the sizzle functionality in jquery (could be done with a static library model or maybe dynamic library model utilizing symlinks.)  As Luke's jquery package is being executed on a local machine, we do have to push forward on javascript guidelines to get it in (definitely can't bundle code executed on the local machine) but we might also be able to save for later portions of the guideline to do with serving via a web server.

*** This bug has been marked as a duplicate of bug 805587 ***