[Pkg-javascript-devel] hello, plus node packaging questions.

Jérémy Lal kapouer at melix.org
Tue Jan 31 12:51:21 UTC 2012


On 31/01/2012 13:40, Andrew Baxter wrote:
> On 31/01/12 12:25, Jonas Smedegaard wrote:
>> On 12-01-31 at 11:46am, Andrew Baxter wrote:
>>> what are the reasons for wanting separate debian packages for each
>>> dependent library of a program like the buddycloud web client? I'm
>>> assuming the idea is to reduce code duplication between packages, but
>>> I'd rather have a definite answer than assume something. Some of the
>>> webclient dependencies are quite small, so if this is the reason, it
>>> could make sense to include these in the webclient package at first
>>> and work on packaging the bigger libraries. For example,
>>> 'normalizecss' is included as a git submodule, and maintained as a
>>> separate project, but only includes a single short css file.
>> Yes, code duplication, which relates to security, convenience and
>> efficiency...
>>
>> You argue from the POV of this single application, buddycloud-client.
>> Try step back a little to get a broader perspective: Users of Debian
>> benefit in multiple ways from reusable code appearing as such.  Some
>> users run DEbian-packaged applications and don't care much how
>> dependencies are resolved, but others run locally hacked together
>> applications and use Debian-packaged libraries.
>>
>> By packaging shared code as shared code, we encourage use of shared
>> code.  Among our users, and also among developers of Debian: when you
>> decide to stuff a piece of shareable code into a consuming package, you
>> essentially hide that code as shareable, and it is highly likely that
>> the next developer will do the same for the exact same piece of code.
>>
>> Or put it differently: Did you verify all existing Debian-packaged Node
>> code for existing use of those small chunks, before proposing to stuff
>> it into buddycloud-client?  Are you certain you are not _introducing_
>> code duplication by doing so? ;-)
>>
>>
> 
> It's OK - I get the point; it's just it helps to have a definite answer as to the reasons when I'm thinking about marginal cases like normalizecss.
> 
>>> I was also wondering whether the packages you're building for nodejs
>>> are built to work with npm? For example this would be useful for
>>> someone who needs to install some node modules not yet in debian - npm
>>> would notice the ones already included and only install the extra
>>> modules which are needed. This is something I can probably answer for
>>> myself by looking at existing packages though.
>> npm is package management for end-users.  dpkg is package management for
>> sysadmins.  Ideally npm would detect Node "packages" already installed
>> via dpkg (but I don't think it does now) but it does not make sense the
>> other way around.
>>
>> Perhaps npm could benefit from a certain hinting provided by dpkg
>> packages Node code.  I am unaware of such need, so someone need to
>> discover and document that (if it exist)...
> 
> OK. If I get the energy, I'll look into how hard it would be to make npm detect installed debian packages.

Considering how npm works,
I really don't understand what advantage that would bring.
Could you explain ?

Regards,

Jérémy.




More information about the Pkg-javascript-devel mailing list