[Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package [and 1 more messages]

[Pirate Praveen]

On വെള്ളി 09 മാർച്ച് 2018 04:48 വൈകു, Ian Jackson wrote:
> But:
> 
>> 2. We won't be able to specify a minimum version of nodejs for these
>> modules.  For example, node-regexpu-core required nodejs >= 6 and
>> this prevented its testing migration for a long time because testing
>> only had nodejs 4 for a long time.
> 
> That is a problem, indeed.  Is this common ?
> Another possibility, though would be to use Breaks.  Eg
> 
>      Package: node-regexpu-core
>      Breaks: nodejs (<< 6~)

Would this stop the package from migrating to testing?
>>> If only a much smaller number of upstream packages have command line
>>> utilities, then we could have the number of JS .deb packages that need
>>> to be maintained by putting the node and browser files into the same
>>> package.
>>
>> I think the following change to point 5 of javascript policy [1] has
>> consensus now.
> 
> Woah, steady on there.  You only just posted this proposal.  It can't
> possibly have consensus yet!  Furthermore, I was mostly asking
> questions and exploring possibilities.

I was trying to summarize it based on my understanding of the responses
so far, it is anyway not final without confirmation from others. At
least the main part of reducing binary and replacing with provides seems
to be accepted without challenges. I agree the exception part was rushed
by me.

> I appreciate that you are keen to move forward, but to that end I
> would encourage you to engage quickly in this discussion, rather than
> waiting a while and then providing a bunch of answers combined with
> jumping straight to a policy change.

I was traveling so could not reply earlier, the wait was not intentional.

>> Change,
>>
>> 5. should generate a node-foo binary package if the script is usable
>> also for Nodejs
>>
>> to
>>
>> 5. should provide node-foo and install package.json in
>> /usr/lib/nodejs/foo if the script is usable also for Nodejs. If script
>> includes a command line tool, it should generate foo (node-foo in case
>> of a name conflict) binary package and declare dependency on nodejs. A
>> separate binary package should be generated if the script requires a
>> newer version of nodejs than available in testing to facilitate proper
>> testing migration.
> 
> This would seem to suggest *three* packages in some cases ?  I'm not
> sure I understand the intent.

May be I was not clear. It would be one binary plus provides or two
binaries in all cases. In case of a script needing newer nodejs features
not available in testing, adding provides to one binary will not be
sufficient to prevent it from migrating to testing.

How about the change given below? (is the intent clear at least even if
disagreement on content remains)

5. should add 'Provides: node-foo' in debian/control and install
package.json in /usr/lib/nodejs/foo, if the script is usable also for
Nodejs.

Exceptions (cases where a provides may be insufficient):
1. should generate binary package 'foo' ('node-foo' in case of a name
conflict) and declare dependency on nodejs, if script includes a command
line tool

2. should generate binary package 'node-foo' in addition to 'libjs-foo',
if the script requires a newer version of nodejs than available in
testing. This is to facilitate proper testing migration (provides will
not be sufficient to block migration to testing before required nodejs
also migrates).

> 
> Also your comments about namespace make me wonder: do many of these
> node scripts have poorly chosen command names ?  Can I get a list of
> them easily somehow ?

apt-file find /usr/bin |grep ^node-

will give most of it, but some packages like mocha only provides
node-mocha so the search should include source package names too.

> I don't think renaming the package only when there is a conflict is a
> good rule of thumb.  Instead, the package should be renamed when
> conflict is likely, even if it hasn't yet occurred.  The same goes for
> command names.

I don't think renaming just anticipating conflicts is good. Renaming has
a cost in extra documentation and causing confusion so it should be best
avoided.

> I think "handlebars" and "uglify" are OK for this, but I don't know
> what the whole ecosystem is like.  The controversy about the name
> "node" itself, and upstream's handling of that, don't give me
> confidence that the node.js upstream community have fully realised
> that the command namespace is a global resource, which they should be
> using with respect for others.
> 
> In practice, as an easier guideline, maybe it would be better to say
> that the command and package should *usually* be renamed, unless the
> script is high propfile and has a good name which is unlikely to
> conflict.

I don't agree. I don't think the benefit outweigh the cost. Changing
node to nodejs costed us so much effort in patching at so many places.
And as soon as we could use node again, we switched back.

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