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/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111023151317.ga26...@rivendell.home.ouaza.com