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

[Florian Brandes]

Thank you very much for clarifying, it did indeed help ;-)

I'll look into packaging these small libraries or maybe talking to
Upstream to include these small libraries in the program itself. 

Thanks, 

Florian

Am Dienstag, den 04.10.2011, 16:35 +0200 schrieb Jonas Smedegaard:
> On 11-10-04 at 03:50pm, Florian Brandes wrote:
> > 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?
> 
> I distinguish between a .deb package and package maintainance officially 
> for Debian.
> 
> A .deb package only needs to function practically.  It can contain 
> horrible install scripts going online during install or erasing your 
> harddisk if your surname is Jensen, or it can be excellent.
> 
> Package maintainance officially for Debian requires the package to not 
> only function practically, but also obey Debian Policy, and also 
> involves relationship with the surrounding Debian and upstream.
> 
> Bundling dependent libraries might very well function practically, and 
> could even be done excellently on that level.  So by my definition is 
> can be a proper .deb package.
> 
> ...but bundling libraries is generally bad on a higher level.  Example: 
> a bug found in a shared library is fixed once, but needs fixing for each 
> and every instance of privately included libraries.
> 
> Even if a library contains only a single line of code, the very fact 
> that it is a library means it is likely reused several places.  I 
> believe a Perl library exists essentialy consisting of a single very 
> long line, providing the correct regular expression for RFC-compliant 
> email (it is a veeeery long regexp!).
> 
> A reason to avoid small libraries is size: Packaging consume space, so 
> packaging five tiny libs separately consumes more space than a single 
> bundle of libs.
> 
> But bundling should be done carefully (if at all): any other pacakage 
> needing a single of the bundled libs need to depend on the bundle, so 
> the bundle should probably contain only libs (not data or binaries or 
> daemons) and the bundled parts should probably be closely related.
> 
> 
> Seems to me that you seek to avoid the tedious packaging work.  Bundling 
> might be less tedious but quite likely not easier: it is more complex to 
> compose bundles properly, and more work to maintain a bundle (e.g. it 
> needs updating every time a single of its components need updating).
> 
> 
> 
> > > If "the job" is just to make a system work however possible, 
> > 
> > Not it is not.
> 
> Ok.  Then it seems we are talking about similar things :-D
> 
> 
> > 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".
> 
> Nah, you excuse me for confusing more than clarifying: It is fine that 
> you use Ubuntu, and also fine if you are interested in lazy "short-cuts" 
> instead of striving for perfection towards Debian ideals.
> 
> Feel free to ask.  I should've asked too what you meant by "debianize" 
> instead of using it against you, as it is not a registered trademark and 
> can mean multiple things :-)
> 
> 
> Regards,
> 
>  - Jonas
> 
> _______________________________________________
> Pkg-javascript-devel mailing list
> Pkg-javascript-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel