On 27 June 2015 at 16:43, Jérémy Lal <[email protected]> wrote: > > > 2015-06-27 15:24 GMT+02:00 Leo Iannacone <[email protected]>: >> >> On 26 June 2015 at 22:57, Thorsten Alteholz <[email protected]> wrote: >> > >> > Hi Bas, >> > >> >>> I'm reluctantly looking into this issue further, but I need to know >> >>> what >> >>> requirements an Node.js module must meet to be eligible for its own >> >>> source package. >> >>> >> >>> What are your requirements for this? >> > >> > >> > from my point of view only the size of the binary package (excluding >> > /usr/share/doc and other meta information) is important. So the 120 bytes >> > of >> > node-isarry is far too little. Up to this point I draw the line at about >> > 5kB. >> > >> > Thorsten >> >> >> Packaging nodejs module has become a nightmare. We should start >> working on bundling the whole node_modules directory per deb package. >> >> That's all. > > > > May i insist that this must not be a general or systematic practice. > Doing so should trigger some lintian info tags at minimum. > > However it makes sense to not distribute separately a bunch of submodules > that are strongly related to the software that needs them, and in addition > that > are not used in other debian packages, especially if they contain a few > lines of > code ! > > Currently the approach we have is adding those modules as patches, and > this is not a good way to do it - not easy to do, to maintain, and is > error-prone. > > It'd be nice to agree on a method for building the source tarball with the > modules > chosen by the maintainer. > The list of modules and their versions must be kept somewhere: > - in debian/watch along with a uupdate-like script to deal with building > tarball > - in debian/source/something > - in debian/copyright ? > > and toolchain must allow downloading/rebuilding source tarball using > mk-origtargz > so that Files-Excluded stays effective. > > Please comment.
This is still hard to maintain because it's not a solution, but only a workaround. And it will still work in wrong way, simply because debhelper was not developed to bundle and track dependencies inside the package itself. You are just forcing the tool to act as you wish. I think finally that we should put a bit more intellectual honesty in that and start to say ourselves that it's not the right way to maintain nodejs package. A better solution could be develop a new a wrapper application around debhelper, able to use it to configure/update/whatever the dependencies and easily-and-quick include them in the package. npm2deb already does many stuffs and facilitates a lot the "debianize" process of a nodejs module. We could extend it to also control and to manage bundled dependencies easily. My 2 cents. L.
signature.asc
Description: GooPG digital signature
_______________________________________________ Pkg-javascript-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
