[Pkg-javascript-devel] Small Node.js packages in NEW

[Leo Iannacone]

On 28 June 2015 at 12:38, Jérémy Lal <kapouer at melix.org> wrote:
>
>
> 2015-06-28 12:02 GMT+02:00 Leo Iannacone <l3on at ubuntu.com>:
>>
>> On 27 June 2015 at 16:43, Jérémy Lal <kapouer at melix.org> wrote:
>> >
>> >
>> > 2015-06-27 15:24 GMT+02:00 Leo Iannacone <l3on at ubuntu.com>:
>> >>
>> >> On 26 June 2015 at 22:57, Thorsten Alteholz <alteholz at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: GooPG digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20150628/3fdc312a/attachment.sig>