Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=457343 --- Comment #12 from Toshio Ernie Kuratomi <a.bad...@gmail.com> 2011-08-31 17:19:26 EDT --- (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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
