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/445Having said this, yes, I understand the desire to build everything from source, and I believe this is a good goal.