Dealing with embedded javascript libraries
Hello,
I would like to discuss our handling of embedded javascript libraries.
In theory, like any other embedded library, they are to be avoided and
we have a lintian warning catching many of the common cases:
http://lintian.debian.org/tags/embedded-javascript-library.html
Unfortunately, blindly replacing the file with a symlink can
create problems of its own. Upstream tested their application
with the version of the library that they ship. Using another
version might break things horribly, an example here:
https://bugs.launchpad.net/ubuntu/+source/wordpress/+bug/816962
Even if the Debian maintainer takes care to ensure the correct
version is used (which is difficult to do, you never know what the next
upstream version of the javascript will do), it's quite possible that he
will have to switch regularly between the embedded version and the
packaged one just because of differing schedules between the two projects.
If the package uses symlinks to directories, those switchs
quickly become painful (and forgetting about them even more, see
for example #639733).
And with javascript libraries, there's no failure at build time,
you only discover much later when something is not working...
(BTW, a large part of what I'm saying also applies to PHP libraries but
the resulting runtimes failures are usually easier to catch and diagnose)
So I'm wondering if we're not giving ourselves bad advice by recommending
to replace those files with symlinks. Most of the time the Debian
maintainer is not knowledgeable enough (or doesn't have the time required
to make the proper assessment) to safely decide to diverge from upstream.
It's good to reduce the workload of the security team but only if we
don't break stuff while doing it.
My current suggestion is to use what I would call opportunistic
replacement of those embedded copies, if the packaged library matches the
embedded one, then provide a symlink instead of a copy and ensure the
dependencies hardcode the current upstream version of the packaged
library (via ${misc:Depends} most likely).
And instead of creating symlinks to directories, we duplicate the
directory hierarchy and we only symlink files so that it's easy to
switch back and forth between the embedded copy and the packaged one.
I have some early prototype code in the wordpress package, see
debian/dh_linktree. It can replace identical files with symlinks
if you pass --replace-only --same-only. It doesn't implement the
dependency generation though. In any case it needs further thoughts
and cleanups.
http://anonscm.debian.org/gitweb/?p=collab-maint/wordpress.git;a=blob;f=debian/dh_linktree;hb=master
What are your thoughts on this topic?
One downside of this approach is that a package like wordpress
would have to be rebuilt when a new upstream version of one of its
javascript libraries is released. (And we don't have bin-nmu for
arch: all currently).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/
Reply to: