On Fri, Jan 17, 2014 at 1:51 AM, Matthias Runge <mrunge@xxxxxxxxxxxxxxxxx> wrote: > Hello everybody, > > could you please tell me, what's the status with JavaScript (client side > libraries) and Web Assets? > > There are quite a few packages bundling e.g. jQuery. we have a review > request for jQuery itself[1] > > So, the Web_Assets guideline[2] and JavaScript guideline[3] isn't really > in production, because it can not be applied to current packages and > even not applied to packages under review, or am I wrong here? > > jQuery comes with several versions, esp. earlier versions are not > compatible with later ones. We couldn't expect to be able to make every > package compatible with jQuery's latest version. How shall this be handled? The plan for jQuery is now outlined at: https://fedoraproject.org/wiki/Changes/jQuery I plan to introduce two jquery packages: js-jquery - jquery 2.x latest - for webapps that use jquery2/don't care about IE6 js-jquery1 - jquery 1.x latest - for webapps that do care about IE6 I personally have no interest in maintaining older jquery versions. It would be totally permissible for someone else to introduce a js-jquery1.7 if that's what they want to do, but then they would be on the hook for backporting the inevitable security fixes and all the other unpleasantness that comes with maintaining code that's considered dead upstream. I already have one package I have to that kind of stuff for: v8. Every month I have to track back some CVE quietly fixed in some recent Chromium release and check if it's some bug the monkeys at Google have introduced subsequently or if I have some backporting to do. Then I backport it, fix Fedora's v8 package (thus fixing it for nodejs and mongodb and even the ruby bindings all at once), and finally I also send nodejs a patch for their bundled copy cause I'm a nice guy like that. :-p Amazing, isn't it? The whole ecosystem benefits from one crazy Fedora maintainer and our insistence that bundling not be permitted. And it this situation, I think it makes perfect sense to carry and old v8 because it is a ridiculously fast moving target and there all all kinds of v8 consumers that benefit from a stable maintained v8 besides nodejs. With jquery it does not make sense. Anything with jquery >= 1.6 (e.g. everything that uses a jquery released in the last four years) can be easily migrated with the aid of jquery-migrate (== an extra <script> tag) so it's not too bad. Anything using a 4+ year old jQuery will be grandfathered in and allowed to bundle until the heat death of the universe, but those packages are probably already affected by several CVEs and that number will only continue to grow. :-( I mean, in what universe can you expect something you just wgetted 5 years ago to still be safe to ship? Webapp developers may suck, but that doesn't mean we have to. If some random application bundles Qt 4.2 because that's what was there when they made the thing, we don't just accept that. We say make it work with the modern Qt we have in the distribution or keep it out. We have a lot of good reasons for this policy, and I think they're more important when it comes to webapps. For years we've taken a hard line with the code that runs on the computers Fedora is run on, but handwaved away the code that is shipped from Fedora servers to end user machines because it's "too hard". That's entirely backwards, and does a great disservice to our users. Going forward we really want to treat JS libraries like the rest of the libraries in Fedora and encourage porting to new releases as soon as possible. That means if a library updates, you have two choices: port to the new version or carry the old version in a separate package where security vulnerabiltiies and the like can be easily tracked. We can't just ship an old copy along with the package and cross our fingers anymore. To go back to the Qt example, there are a lot of apps that were never ported to Qt 4. So we have a qt3 package, so issues with that old version of Qt can be tracked in one place, and fixed once for all of those apps. We just don't let every app bundle qt3 because they don't use the new hotness. I don't see any reason why we should treat jQuery any differently. If we'd have just treated v8 like the code it's designed to execute, there would be six different security vulnerabilities in nodejs nobody would know about, and that's awful. But because we're crazy, there are instead six security vulnerabilities that are fixed even for those individuals that use that bundled version. I really want our JS story to be more like the latter and less like the former that thankfully never happened. :-) I know it's a giant pain in the butt, but the whole open source web applications ecosystem will be better for it. > Are currently all packages bundling jQuery blocked by [1]? I believe that is the case yes. > Even if they > use a different version than provided by the package under review? Especially if they use a different version. See my novel above. :-) If they really, really need the old version, again nothing is stopping anyone from making a parallel-installable compat-js-jquery-1.whatever package. I just don't think bundling is the right call for these situations. > I agree, the current situation is a mess, from packagers perspective. > Sadly, I wouldn't expect any real change there, as most developers > simply don't care and frameworks like Django even suggest bundling libs > directly in applications [4]. I believe Adam already figured out something in the case of django's tinymce package that seemed generally applicable to django JS packages in general. I haven't had the chance to go over that thread in detail yet, unfortunately. :-( -T.C. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
