[Pkg-javascript-devel] npm2deb, OpenPGP.js, and dependency management [was: Re: Looking for help Re: Bug#787774]

Daniel Kahn Gillmor dkg at debian.org
Thu Feb 1 15:34:44 UTC 2018

Thanks for the suggestions, Praveen and Jérémy!

On Thu 2018-02-01 16:30:41 +0530, Pirate Praveen wrote:
> This is a bug in node-node-uuid, which is reported already. A workaround
> is to use older version of the deb from buster.

I supposed you're talking about https://bugs.debian.org/887069 which it
looks like Jonas just fixed.  thanks!  I've merged it with three other
reports, including my own.

> salsa.debian.org/js-team

It looks like i haven't been added to this team yet.  Is there an
interest in team maintenance of OpenPGP.js, or any of its

If so, i'd request to join the team and i'd try to follow team standards
if i can find them.  If there's no interest in co-maintenance, then i'd
just as soon put everything in the debian/ namespace and follow my own
packaging practices.  But i'd really prefer to co-maintain if there's an
offer there.  If there is, can i be added to the js-team group?

As for OpenPGP.js, I'm concerned because of the build-time dependency
tree reported by npm2deb:

0 dkg at sid:~/src/node-openpgp$ npm2deb depends -b openpgp
NPM                                               Debian
openpgp (2.6.2)                                   None
├─ node-fetch (^1.3.3)                            node-fetch (1.7.3-1)
└─ node-localstorage (~1.3.0)                     None

0 dkg at sid:~/src/node-openpgp$ npm2deb depends -B openpgp
Build dependencies:
NPM                                               Debian
asmcrypto-lite (^1.0.0)                           None
babel-core (^6.26.0)                              None
babel-preset-es2015 (^6.3.13)                     None
babelify (^8.0.0)                                 None
browserify-derequire (^0.9.4)                     None
chai (~4.1.2)                                     node-chai (4.1.2+dfsg-1)
es6-promise (^4.1.1)                              node-es6-promise (4.1.1+ds-2)
grunt (~1.0.1)                                    grunt (1.0.1-8)
grunt-browserify (~5.2.0)                         None
grunt-contrib-clean (~1.1.0)                      node-grunt-contrib-clean (1.0.0-1)
grunt-contrib-connect (~1.0.2)                    None
grunt-contrib-copy (~1.0.0)                       node-grunt-contrib-copy (1.0.0-2)
grunt-contrib-jshint (~1.1.0)                     None
grunt-contrib-uglify (~3.2.1)                     node-grunt-contrib-uglify (2.0.0+dfsg-1)
grunt-contrib-watch (^1.0.0)                      None
grunt-jsbeautifier (~0.2.10)                      None
grunt-jscs (^3.0.1)                               None
grunt-jsdoc (~2.2.0)                              None
grunt-mocha-istanbul (^5.0.1)                     None
grunt-mocha-test (~0.13.3)                        None
grunt-saucelabs (9.0.0)                           None
grunt-text-replace (~0.4.0)                       None
istanbul (~0.4.1)                                 None
mocha (~4.0.1)                                    node-mocha (4.0.1-3)
rusha (^0.8.3)                                    None
sinon (^1.17.3)                                   node-sinon (1.17.6-1)
whatwg-fetch (~2.0.3)                             libjs-fetch (2.0.3-1)
zlibjs (~0.3.1)                                   None

This seems to imply that we might need to review, build, and maintain
~20 new debian packages in order to be able to build and maintain
OpenPGP.js in debian.  is that right?  I'm hoping that some of these are
inappropriate or unnecessary for the debian build -- like hooks into
external continuous integration systems (grunt-saucelabs?
grunt-contrib-connect? which clearly won't be run from the debian
buildds), or fallback-polyfill stuff (asmcrypto-lite? rusha? zlibjs?)
that we can skip because our own dependency management can ensure that
it's not needed.

But i don't know how to judge these decisions yet.

I'm also noticing that things like babel-preset-es2015 and babel-core
are listed as "None" in the output above, though
node-babel-preset-es2015 and node-babel-core appear to be present in
sid.  so maybe npm2deb is confused?

lastly, it looks to me like the boilerplate dropped by npm2deb still
points to alioth, not salsa.  

> We usually work with tarballs and use gbp import-dsc --pristine-tar for
> the dsc file created by npm2deb create.

is there a specific example that you want to point me (and other
relative newbies) to that is well-maintained and modern?  for example, i
work with tarballs too, but i prefer to link them to upstream's revision
control history (e.g. i put upstream-vcs-tag into debian/gbp.conf where
possible) so that the relationships between the threads of development
are visible in git.

any and all guidance welcome!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20180201/c6fffe73/attachment.sig>

More information about the Pkg-javascript-devel mailing list