<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-06-28 12:02 GMT+02:00 Leo Iannacone <span dir="ltr"><<a href="mailto:l3on@ubuntu.com" target="_blank">l3on@ubuntu.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 27 June 2015 at 16:43, Jérémy Lal <<a href="mailto:kapouer@melix.org">kapouer@melix.org</a>> wrote:<br>
><br>
><br>
> 2015-06-27 15:24 GMT+02:00 Leo Iannacone <<a href="mailto:l3on@ubuntu.com">l3on@ubuntu.com</a>>:<br>
>><br>
>> On 26 June 2015 at 22:57, Thorsten Alteholz <<a href="mailto:alteholz@debian.org">alteholz@debian.org</a>> wrote:<br>
>> ><br>
>> > Hi Bas,<br>
>> ><br>
>> >>> I'm reluctantly looking into this issue further, but I need to know<br>
>> >>> what<br>
>> >>> requirements an Node.js module must meet to be eligible for its own<br>
>> >>> source package.<br>
>> >>><br>
>> >>> What are your requirements for this?<br>
>> ><br>
>> ><br>
>> > from my point of view only the size of the binary package (excluding<br>
>> > /usr/share/doc and other meta information) is important. So the 120 bytes of<br>
>> > node-isarry is far too little. Up to this point I draw the line at about<br>
>> > 5kB.<br>
>> ><br>
>> >   Thorsten<br>
>><br>
>><br>
>> Packaging nodejs module has become a nightmare. We should start<br>
>> working on bundling the whole node_modules directory per deb package.<br>
>><br>
>> That's all.<br>
><br>
><br>
><br>
> May i insist that this must not be a general or systematic practice.<br>
> Doing so should trigger some lintian info tags at minimum.<br>
><br>
> However it makes sense to not distribute separately a bunch of submodules<br>
> that are strongly related to the software that needs them, and in addition<br>
> that<br>
> are not used in other debian packages, especially if they contain a few<br>
> lines of<br>
> code !<br>
><br>
> Currently the approach we have is adding those modules as patches, and<br>
> this is not a good way to do it - not easy to do, to maintain, and is<br>
> error-prone.<br>
><br>
> It'd be nice to agree on a method for building the source tarball with the<br>
> modules<br>
> chosen by the maintainer.<br>
> The list of modules and their versions must be kept somewhere:<br>
> - in debian/watch along with a uupdate-like script to deal with building<br>
> tarball<br>
> - in debian/source/something<br>
> - in debian/copyright ?<br>
><br>
> and toolchain must allow downloading/rebuilding source tarball using<br>
> mk-origtargz<br>
> so that Files-Excluded stays effective.<br>
><br>
> Please comment.<br>
<br>
</div></div>This is still hard to maintain because it's not a solution, but only a workaround.<br>
<br>
And it will still work in wrong way, simply because debhelper was not developed to bundle and track dependencies inside the package itself.<br>
You are just forcing the tool to act as you wish.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
My 2 cents.<br></blockquote><div></div></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"><span style="line-height:normal">I don't agree on a debhelper wrapper - including submodules only makes sense when</span></div><div class="gmail_extra"><span style="line-height:normal">doing tarball generation (typically before importing into deb package VCS), </span><span style="line-height:normal">not at build time.</span></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I was saying that basically all we need to have is a specific "get-orig-source" script</div><div class="gmail_extra">that <span style="line-height:normal">is feeded by the watch file and an additional config file (listing strict versions of submodules).</span></div><div class="gmail_extra"><span style="line-height:normal">It's a simple solution, it's easy to understand, debug, and maintain.</span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="line-height:normal">npm2deb could do that job (and even populate an initial config file based on what's in</span></div><div class="gmail_extra"><span style="line-height:normal">upstream package.json). It should probably also dedupe dependencies, and use</span></div><div class="gmail_extra"><span style="line-height:normal">mk-origtargz in the process because it does some things right (and takes Files-Excluded</span></div><div class="gmail_extra"><span style="line-height:normal">into account).</span></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="line-height:normal"><br></span></div><div class="gmail_extra"><span style="line-height:normal">Jérémy.</span></div><div class="gmail_extra"><br></div></div>