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

Thu Feb 1 16:11:48 UTC 2018

On വ്യാഴം 01 ഫെബ്രുവരി 2018 09:04 വൈകു, Daniel Kahn Gillmor wrote:
> 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
> build-dependencies?
I think it would be a good thing to maintain it in team. Since many
dependencies are shared with packages already maintained in team.
> 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?
You can request access to the team.
>
> 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
> Dependencies:
> 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.
I have replied to your ITP about grunt. Yes, many of this can be
ignored. You will need to replace browserify with webpack.
> 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?
yes, its a bug in npm2deb.
> lastly, it looks to me like the boilerplate dropped by npm2deb still
> points to alioth, not salsa.  
>
That should be updated, for this as well as in npm2deb.
>> 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.
It is just how we have been working. May be you can convince the team to
switch to that workflow.
> any and all guidance welcome!
>
>     --dkg


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