Re: Javascript team policy and rejection of node-three binary package [and 1 more messages]
Pirate Praveen writes ("Re: Javascript team policy and rejection of node-three binary package"):
> On ചൊവ്വ 06 മാർച്ച് 2018 07:42 വൈകു, Ian Jackson wrote:
> > This could be solved by dropping the nodejs dependency from all the
> > nodejs module packages and requiring top-level applications to depend
> > on nodejs.
>
> I see two problems with that approach. 1. It makes these modules
> installable but unuseable in architectures where nodejs itself is not
> available.
I don't think 1 is a problem.
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~)
> I think separate binary should be allowed at least in the second case.
For me it's not a question of it being *allowed*. I appreciate that a
lot of what is going on here must seem to you very much a question of
the Debian establishment wielding power. But I would prefer to think
about what would be best. If it is best to use another package then
it should not just be "allowed", but indeed encouraged, recommended or
mandated.
But I don't think we have quite explored all the issues yet.
> > Does handlebars contain anything that is useful to run directly ?
>
> handlebars is templating system widely used, not only in nodejs. It has
> binding for different languages (like ruby-handlebars-assets) and also a
> command line interface. The command line can be used for compiling
> handlebars templates.
Right, so you said in the other branch of the thread.
Pirate Praveen writes ("Re: [Pkg-javascript-devel] Javascript team policy and rejection of node-three binary package"):
> On ചൊവ്വ 06 മാർച്ച് 2018 07:57 വൈകു, Ian Jackson wrote:
> > Is this going to be common ? The Javascript ecosystem has large
> > numbers of small packages - but do they mostly contain just JS
> > libraries or do they generally all contain command line utilities
> > too ?
>
> Libraries are majority, but there are many command line utilities too
> (mocha, uglifyjs, handlebars etc).
Right.
> > 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 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.
> 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.
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 ?
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 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.
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: