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. _______________________________________________ Pkg-javascript-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
