On Fri, 25 Apr 2014 01:16:04 +0100 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> wrote:
> I don't think that we should go and do the tedious work of repack > thousands of packages because of this, with no real benefit in terms > of freedom (or any other) for our users -- provided that we depend > and link to the canonical versions in the binary packages. Talk to upstream, get them to package the unminified JS or no JS in their releases, then minify during the build. If the built version matches a packaged version, then do the dh_link but not otherwise. If the JS APIs were sufficiently stable that these packages could be used much as with a C library or python module, then there would be less of an issue. In reality, the packaged JS is not always a working match with the JS that the package needs or was used by upstream during development. When the versions do match, the maintainer can use the dh_link support but other times need to use a known / newer version. So when the JS package does move ahead, the package can continue to use the working version until any migrations are complete upstream. We don't have SONAMEs or other mechanisms to do this with javascript, so the source code of the JS which the package requires does need to be within the source code of that package. Otherwise, it makes it all but impossible to debug the JS when the packaged versions migrate. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
