Bug 857992

Summary: Review Request: JQuery - Fast, concise library that simplifies how you use JavaScript
Product: [Fedora] Fedora Reporter: Gregor Tätzner <gregor>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: felix, jamielinux, jreznik, lmacken, mrunge, msrb, msuchy, package-review, shawn, tchollingsworth, volker27, vondruch
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-19 12:51:11 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Gregor Tätzner 2012-09-17 13:24:59 EDT
Another try of getting jquery into fedora ;)...

Spec URL: http://brummbq.fedorapeople.org/jquery.spec
SRPM URL: http://brummbq.fedorapeople.org/jquery-1.7.2-2.fc17.src.rpm
Description: 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.
Fedora Account System Username: brummbq
Comment 1 Gregor Tätzner 2012-09-17 13:26:43 EDT
*** Bug 805587 has been marked as a duplicate of this bug. ***
Comment 2 Matthias Runge 2012-09-17 16:26:12 EDT
I'm asking myself currently, if it is really desirable to make a package. 
Reason: many web based frameworks and other packages bundle jquery in any form. Mostly, they are tailored to a specific jquery version, so unbundling is not really an option. 

When jquery becomes a package: what happens with the packages bundling (more or less) silently jquery? Take django as example. It's upstream voted against unbundling; Security reasons are also not that problem, because it's client side, and should/will be interpreted in a sandbox.

To be more productive:
I'd define a <Directory> in your httpd-conf snipped, and to make it more readable, I'd put that everything in a separate file.
Comment 3 Gregor Tätzner 2012-09-17 17:11:27 EDT
Well, I'm not sure...bundling is bundling. Do we have an official position about javascript libraries? But if upstream is really shipping unmodified jquery libs, I don't see why we couldn't provide packages for that...in the worst case in form of parallel-installable packages containing different jquery versions.

Anyway if you would be able to obtain a global exception for jquery* bundling I would drop this package happily :)
Comment 4 Felix Kaechele 2012-09-22 08:01:00 EDT
As of now there is no best practice for bundling (or unbundling) JavaScript libraries.
The issue raises a few questions: For example, what _may_ be bundled, what _must not_ be bundled.
Think of jQuery plugins: Do we package each plugin seperately? What if a webapp bundles a plugin that is only part of that particular webapp?
Do we unbundle it as well?
I guess we need to fundamentally discuss this. I'm unsure if we can make this in the F18 timeframe.
Comment 5 Matthias Runge 2012-09-26 04:46:47 EDT
jquery: latest version is (currently) 1.8.2. , 1.8.1 was released on Aug 30, so you'l need to update this package.

In my experience, esp. web developers are pretty ignorant in bundling/copying external code. And also, most of them don't care for backwards compatibility.

For example: Django developers: they said about the request to unbundle: Not having external dependencies is a design choice of Django.
https://code.djangoproject.com/ticket/17982
Django still uses jquery 1.4.2, and I don't see, this will change in the near future.

jquery's release notes list some changes affecting backwards compatibility:
http://blog.jquery.com/2012/08/09/jquery-1-8-released/

When breaking other's packages by upgrading to newer versions, you're also requested to fix those issues. I'm sure, I don't want to do that.
Comment 6 Gregor Tätzner 2012-09-26 14:38:45 EDT
(In reply to comment #4)
> Think of jQuery plugins: Do we package each plugin seperately? What if a
> webapp bundles a plugin that is only part of that particular webapp?
> Do we unbundle it as well?
> I guess we need to fundamentally discuss this. I'm unsure if we can make
> this in the F18 timeframe.

Regarding jQuery plugins I think it does not harm if we put everything together in one package? Of course if a js lib is unique/forked it doesn't make sense to distribute it separately.


(In reply to comment #5)
> jquery: latest version is (currently) 1.8.2. , 1.8.1 was released on Aug 30,
> so you'l need to update this package.

If I'm obliged to build it from source I've a problem because nodejs is still not in fedora. Or would it be ok to use the ready-to-use version from the website?

> 
> In my experience, esp. web developers are pretty ignorant in
> bundling/copying external code. And also, most of them don't care for
> backwards compatibility.
> 
> For example: Django developers: they said about the request to unbundle: Not
> having external dependencies is a design choice of Django.
> https://code.djangoproject.com/ticket/17982
> Django still uses jquery 1.4.2, and I don't see, this will change in the
> near future.

agreed, in such cases we should respect the decision of upstream.

> jquery's release notes list some changes affecting backwards compatibility:
> http://blog.jquery.com/2012/08/09/jquery-1-8-released/
> 
> When breaking other's packages by upgrading to newer versions, you're also
> requested to fix those issues. I'm sure, I don't want to do that.

I think we must provide different jquery packages right from the beginning i.e.: jquery1.7; jquery1.8 and use them explicitly as deps in the packages. If the maintainer knows for sure that his app supports the next jquery release he can bump it manually and go to a "higher" jquery package.
Comment 7 T.C. Hollingsworth 2013-01-17 04:09:40 EST
Node.js is now available in Fedora 18 and Rawhide and should no longer block this package.
Comment 8 Gregor Tätzner 2013-01-18 08:27:14 EST
(In reply to comment #7)
> Node.js is now available in Fedora 18 and Rawhide and should no longer block
> this package.

aye, node.js is a big step forward but I need also npm to install 'grunt'. The JQuery buildsystem has changed quite a bit in recent releases.
Comment 9 Gregor Tätzner 2013-04-12 06:17:29 EDT
@T.C.
Are you planning to package nodejs-grunt* (also grunt-init, grunt-cli). I've looked briefly over them and I worry that not all nodejs deps for grunt are fulfilled in fedora 18.
Comment 10 T.C. Hollingsworth 2013-04-25 04:51:46 EDT
I need a test case to finish up npm2rpm, so might as well kill two birds with one stone.  ;-)

For the record, the missing deps are:
└─┬ grunt@0.4.1
  ├── colors@0.6.0-1
  ├── dateformat@1.0.2-1.2.3
  ├── eventemitter2@0.4.11
  ├─┬ findup-sync@0.1.2
  │ └── lodash@1.0.1
  ├── hooker@0.2.3
  ├── iconv-lite@0.2.8
  ├─┬ js-yaml@2.0.4
  │ └─┬ argparse@0.1.13
  │   ├── underscore@1.4.4
  │   └── underscore.string@2.3.1
  ├── lodash@0.9.2
  └── underscore.string@2.2.0rc

I can probably get these up for review next week sometime.
Comment 11 T.C. Hollingsworth 2013-04-25 05:05:03 EDT
Oops, forgot about grunt-cli and grunt-init.  The full list of packages is really:
├─┬ grunt@0.4.1
│ ├── colors@0.6.0-1
│ ├── dateformat@1.0.2-1.2.3
│ ├── eventemitter2@0.4.11
│ ├─┬ findup-sync@0.1.2
│ │ └── lodash@1.0.1
│ ├── hooker@0.2.3
│ ├── iconv-lite@0.2.8
│ ├─┬ js-yaml@2.0.4
│ │ └─┬ argparse@0.1.13
│ │   ├── underscore@1.4.4
│ │   └── underscore.string@2.3.1
│ ├── lodash@0.9.2
│ └── underscore.string@2.2.0rc
├─┬ grunt-cli@0.1.7
│ ├─┬ findup-sync@0.1.2
│ │ └── lodash@1.0.1
│ └── resolve@0.3.1
└─┬ grunt-init@0.2.0
  ├── colors@0.6.0-1
  ├── hooker@0.2.3
  └─┬ prompt@0.1.12
    ├── async@0.1.22
    ├── pkginfo@0.3.0
    └─┬ winston@0.5.11
      ├─┬ loggly@0.3.11
      │ ├── request@2.9.203
      │ └── timespan@2.2.0
      └── stack-trace@0.0.6

If you want to help out with getting a head start on the reviews that will be needed, one of grunt-init's deps (winston) is already awaiting review in bug 911060.
Comment 12 Jamie Nguyen 2013-06-23 14:06:20 EDT
I didn't realise you'd made a fancy list of dependencies T.C.! I would have used it if I'd bothered to look.. Anyway I've packaged grunt, grunt-cli and grunt-init and they're all now up for review :)
Comment 13 T.C. Hollingsworth 2013-06-25 17:27:15 EDT
(In reply to Jamie Nguyen from comment #12)
> I didn't realise you'd made a fancy list of dependencies T.C.! I would have
> used it if I'd bothered to look.. Anyway I've packaged grunt, grunt-cli and
> grunt-init and they're all now up for review :)

That list was actually generated by npm.  To get it, do something like:
mkdir /tmp/foo
cd /tmp/foo
npm install bar
npm ls

Comes in handy when figuring out exactly how much work something will be to package.  ;-)
Comment 14 T.C. Hollingsworth 2013-09-19 08:20:11 EDT
devDependencies for jquery that still need to be packaged:
"archiver": "~0.4.9",
"grunt-compare-size": "~0.4.0",
"grunt-contrib-watch": "~0.5.3",
"grunt-git-authors": "~1.2.0",
"grunt-jsonlint": "~1.0.0",
"gzip-js": "0.3.2",
"testswarm": "~1.1.0",
"requirejs": "~2.1.8"

Also, this one is ineligible for Fedora due to its use of the "evil" JSON license, and will need to be patched out:
"grunt-contrib-jshint": "~0.6.4",

It's only used in the test suite so that's not a big deal.
Comment 15 Vít Ondruch 2014-02-03 09:03:26 EST
Can't see sizzle between dependencies you list ...
Comment 16 T.C. Hollingsworth 2014-03-19 12:51:11 EDT
This bug is now being closed duplicate of the review request for js-jquery1, which provides the latest version of the 1.x jQuery branch.  Most web applications depend on this version.

If your application depends on jQuery 2.x, please manually change its dependency to bug 1078368.  Thanks!

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