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

[Jérémy Lal]

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).


Jérémy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20150628/82b40b4e/attachment.html>