[Pkg-javascript-devel] Debian Javascript Policy

Jonas Smedegaard dr at jones.dk
Sat Oct 15 13:46:12 UTC 2011


On 11-10-15 at 11:20am, Jérémy Lal wrote:
> On 15/10/2011 08:21, David Paleino wrote:
> > I started a first draft, based on the recent emails, of a 'Debian 
> > Javascript Policy'. I feel like it's missing lots of things though, 
> > so any help is much appreciated.
> > 
> > http://wiki.debian.org/Teams/pkg-javascript/Policy
> 
> Thank you a lot for this.

Yes, great initiative!

Since we have now grown to not only do packaging but also formulating 
Policy, I took the liberty to rename our team page to be more wiki-like 
(not simply mirroring what was limited by Alioth naming convention):

http://wiki.debian.org/Javascript

...and here is therefore (unsurprisingly) new location of Policy: 

http://wiki.debian.org/Javascript/Policy


> We still have to choose if using /usr/share/nodejs as a place to put 
> native (i mean pure js) node modules is a good idea. It certainly is 
> not a bad one, but won't it disturb node users ? They are used to find 
> node modules in something like /usr/lib/node.

Could you elaborate on the situations that the system path is used 
directly - as opposed to letting Node resolve it?

I mean - would any *code* break from using an unusual path in Debian (as 
is the case e.g. for the issue of renaming the node binary to nodejs), 
or does it only affect habbits among Node developers manually looking up 
what is available to them on this machine, while coding?


> Suggestion :
> 
> I propose to follow python and ruby package naming conventions, which 
> are simpler, and in many cases just stick to the upstream name, see 
> [3] but please answer here. Those packaging teams are older and more 
> experienced, and they certainly choosed those namings for very good 
> reasons. Some of them :
> * libnode-foo is uglier than node-foo.

> * node-foo is often the upstream name, no difference between source 
>   and binary package names.

> * node-foo can contain an executable. Most packages can be used as 
>   libs (require'able), and some of them provide an executable wrapping 
>   them. They are often small, especially the executable, so providing 
>   two packages libnode-foo and foo is not justified. Then we end up 
>   with a libnode-foo package, containing an executable, which is 
>   confusing.
>   I think that is the main reason for the ruby team to drop the "lib" 
>   prefix. (i'll take some time to dig through their mailing list, this 
>   move was made this summer).
> 
> This would imply renaming many existing javascript packages, so maybe 
> we could restrict the naming scheme to node only, instead of js and 
> node.

I agree with this renaming for Node-based Javascript.

I see no reason for changing the naming scheme for classic Javascript: 
To me the main argument for renaming is that Node libraries can be seen 
as sub-packages belonging to node itself.  Since there is no one package 
for which classic Javascript can be said to derived from, it does not 
IMO apply similarly there.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20111015/6235183a/attachment.pgp>


More information about the Pkg-javascript-devel mailing list