On Mon, 31 Aug 2015 at 16:50 Raphael Hertzog <hert...@debian.org> wrote:
> In both cases, I worked around the problem by shipping the upstream > sources in debian/missing-sources/ but I did not support doing changes > there and did not rebuild the embedded libraries. > I haven't been paying lots of attention to this thread, however in the past that has been my strategy too. If I did the minimization myself in the Debian package, or used js from an existing Debian package, I would be seriously worried about introducing bugs. There are lots of potential issues here: * Different versions used. * Bugs in the minimization process. * Upstream may have made changes to js code before including it from third parties. Some of these packages, the js is only a small part of the full functionality. Or I just want to package it quickly because it is a required dependency of the package I really need. Typically these packages don't have any js testing either, so it is not always possible to know you broke some obscure feature that requires a specially crafted input file to enable. Maybe lack of testing is the real issue that needs to get resolved first? As an example, my own package - not yet in Debian - I was forced to modify moment-timezone-with-data.js as downloaded from upstream, because without this kludged modification, pipeline+slimit combined would completely break the js to the point that browsers wouldn't touch it. I reported this against django-pipeline in March, no responses yet. Actually I don't really understand where the bug is, most likely django-pipeline or slimit. https://github.com/cyberdelia/django-pipeline/issues/445 Having said this, yes, I understand the desire to build everything from source, and I believe this is a good goal.
