dr at jones.dk
Tue Oct 4 14:35:52 UTC 2011
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
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 :-)
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature