On 28 June 2015 at 12:38, Jérémy Lal <kapo...@melix.org> wrote: > > > 2015-06-28 12:02 GMT+02:00 Leo Iannacone <l...@ubuntu.com>: >> >> On 27 June 2015 at 16:43, Jérémy Lal <kapo...@melix.org> wrote: >> > >> > >> > 2015-06-27 15:24 GMT+02:00 Leo Iannacone <l...@ubuntu.com>: >> >> >> >> On 26 June 2015 at 22:57, Thorsten Alteholz <alteh...@debian.org> >> >> 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. > > > > I don't agree on a debhelper wrapper - including submodules only makes sense > when > doing tarball generation (typically before importing into deb package VCS), > not at build time. > > I was saying that basically all we need to have is a specific > "get-orig-source" script > that is feeded by the watch file and an additional config file (listing > strict versions of submodules). > It's a simple solution, it's easy to understand, debug, and maintain. > > npm2deb could do that job (and even populate an initial config file based on > what's in > upstream package.json). It should probably also dedupe dependencies, and use > mk-origtargz in the process because it does some things right (and takes > Files-Excluded > into account).
Sounds good (and it's the kind of wrapper I was thinking about). If you have time, please prepare a pull request. L. -- Ubuntu Member - http://launchpad.net/~l3on Home Page - http://leoiannacone.com GPG Key Id - 0xD282FC25
signature.asc
Description: GooPG 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