On Mon, Dec 19, 2016 at 4:30 PM, Daniel Pocock wrote:
> - 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,
Daniel Pocock writes:
> - 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.
Those packages would be similarly buggy in Debian, if so.
> What is the latest opinion on when
Hello Daniel,
There has been extensive discussion of this on debian-devel over the
past few months. Though it was mainly about nodejs libs, the discussion
applies to libjs-* packages too.
The outcome of the discussions:
- the advantages of packaging these libs separately outweigh the
On 14526 March 1977, Daniel Pocock wrote:
> - 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
Hi Daniel,
On 19-12-16 09:30, Daniel Pocock wrote:
> - 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
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
6 matches
Mail list logo