which JavaScript dependencies really need a separate package?
I had a look at packaging homer-ui (ITP[1]) for HOMER[2]. It is a
powerful web application based on AngularJS for troubleshooting SIP
applications. It is particularly useful for troubleshooting many of the
SIP products we include in Debian and also for learning about SIP, SDP
and RTP.
There are a lot of JavaScript libraries included, most from the
AngularJS world, and it is unlikely I would personally make a package of
every one that doesn't already exist in Debian.
I opened an RFP bug for each and used those to block the HOMER ITP bug
so I will see if other people package any of the dependencies for other
projects. If the list of outstanding things becomes smaller I may step
in to get the remaining ones packaged.
- While looking through the list, I noticed that some of them (or at
least files with similar names) are also included within other web
packages. What is the latest opinion on when JavaScript libs can be
included in a web application package?
- For those JavaScript libs that have complicated build systems that are
not (yet) supported on Debian, is it reasonable for a package like
homer-ui to simply include the intermediate product of the build, just
before it is minified, into the Debian source package? This may not be
the "preferred form of modification", but it is not difficult to make
modifications to it.
- The FTP masters have also expressed concern about the standalone
packaging of very small[3] JavaScript dependencies. Is that still the
same for stretch and beyond?
Regards,
Daniel
1. https://bugs.debian.org/837662
2. http://sipcapture.org/
3.
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-June/010692.html
Reply to: