Re: [Pkg-javascript-devel] hello, plus node packaging questions.
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? ;-) 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)... Regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] hello, plus node packaging questions.
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. thanks, andy ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
