[Pkg-javascript-devel] packaging node applications in Debian

Florian Brandes florian.brandes at gmx.de
Tue Oct 4 13:50:23 UTC 2011


Am Dienstag, den 04.10.2011, 15:22 +0200 schrieb Jonas Smedegaard:
> Hi Florian and Jérémy,
> 
> On 11-10-04 at 01:49pm, Florian Brandes wrote:
> > Am Dienstag, den 04.10.2011, 13:41 +0200 schrieb Jérémy Lal:
> > > On 04/10/2011 13:28, Florian Brandes wrote:
> > > > I looked at other libnode* packages and they appear to have less 
> > > > (or none) dependencies. Packaging 12 packages for only one package 
> > > > to work seems rather...cumbersome.
> > > 
> > > This is troublesome for me, too.
> > > Hell, even npm itself has its dozen dependencies...
> > > I feel there is something wrong with blindly making debian packages 
> > > out of those.
> > > 
> > > I'm trying to find good arguments against that practice :
> > > * too small packages - sometimes even only a few lines of code
> > > * most of the time, only one dependency
> > > * anyone can make a package in npm repository. Even if it's a package
> > >   nobody but its author will ever use. There is no quality checks.
> 
> A package needing other code to work is not in itself an argument to 
> seek shortcuts to ease packaging.
> 
> Florian only mentioned the number of dependent library, not if those 
> dependencies were silly or lousy.
> 
> I agree that one-liner libraries are silly.  The proper approach there 
> is to get in touch with upstream and discuss writing code lines instead 
> of dependency lines.
> 
> I agree that lousy quality libraries should be avoided.  But a 
> consequence of that is that packages depending on lousy libs should be 
> avoided too - insane to then pull in the lousy libs with npm!!!
> 
> 
> > Would it make sense for normal Debian (Ubuntu) users to have and 
> > install node packages? If so, would maybe a GUI to npm do the job?
> 
> Depends on how do you define "the job".
> 
> If a package does not contain all runtime code but at install time needs 
> to go online (by use of npm) to fetch some parts, then that package may 
> technically be a .deb package but cannot be part of Debian.

so what about the approach to bundle the package prior to packaging?
Doing so should include all these "silly" dependencies (I actually don't
know whether they are silly, I haven't looked at the code of those
libraries) and neglect the need to go online during build time. 
In your definition, is this a proper .deb package?
> 
> If "the job" is just to make a system work however possible, 

Not it is not.

> then sure - 
> installing Windows might do "the job" or bypassing the APT packaging 
> system and use npm instead might, or creating an ugly .deb package to 
> mix APT with npm might.  And you can call that "debianize" if you want,

I don't.  

> but you will run into trouble discussing with e.g. me, as I assume 
> "debianize" is used to refer to doing things "the Debian way" which it 
> is not when using npm.

For reference: I do not work directly with Debian, I work with a
Debian-derived distribution (Ubuntu). So excuse me, if I have to ask
what exactly debianize means, or how it is proper to package programs
"the Debian way". 

Regards, 

Florian




More information about the Pkg-javascript-devel mailing list