[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

The "node" command in Debian



(please follow-up to debian-devel only)
Hi Debianites,

As you may know[0], there are currently two packages in Debian
experimental providing a "node" binary.

[0] http://lists.debian.org/debian-devel/2010/08/msg00568.html

The node.js project
-------------------
One is from the node.js project.  It was renamed from "server" to
"node" on March 3, 2009.  The purpose of this tool is to run servers
and other event-based programs written in Javascript.

The maintainer for this package in Debian has written[1]:

| not having /usr/bin/node as nodejs binary path will without any
| doubt render nodejs package unuseful for a vast majority of users.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=611698

The LinuxNode project
---------------------
The other is a frontend to libax25, an AX.25 implementation for Linux.
Hardware implementations of AX.25 are apparently called "terminal node
controllers" or "nodes" for short; hence this Linux-based
implementation was called LinuxNode and its binary called "node".  It
was introduced in January, 1996.  It seems that its family tree also
includes (unpackaged) implementations named AWZNode and FlexNode.

The node package does not seem to have a very active maintainer since
Joop Stakenborg retired.  On the debian-hams list, we read[2]:

| As a continuous very long term (about 1994) user of kernel ax25 I
| object strongly to this request which will affect far more users
| world-wide than just a few nodejs users.

[2] http://lists.debian.org/debian-hams/2010/08/msg00032.html

Debian policy
-------------
Both of these projects are, of course, insane to use such a generic
binary name.  But Debian policy does not say "you must not use such a
generic name unless you are a net.god" --- only common sense does.

Problem: scripts may use the 'node' name to refer to either of these
programs.  Which should get the name?  You decide, based not on
popularity or priority but --- well, based on whatever makes sense.

If no consensus emerges, policy §10.1 in its Solomon-like wisdom says
_both_ commands must be renamed.  I hope we can do better.  I will be
happy to file release-critical bugs against both packages to that
effect if not.

With hope,
Jonathan

Disclaimer: I am ignorant about both packages.  Some naïve part of
me believes that it will be possible for mature people not ignorant
about them to figure out a reasonable solution.


Reply to: