On Fri, Jan 17, 2014 at 1:51 AM, Matthias Runge
libraries) and Web Assets?
There are quite a few packages bundling e.g. jQuery. we have a review
request for jQuery itself
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:
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
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
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
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 ?
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
I agree, the current situation is a mess, from packagers
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 .
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. :-(