Bug#614907: nodejs/node command conflict: why can't we have both?
- To: firstname.lastname@example.org
- Subject: Bug#614907: nodejs/node command conflict: why can't we have both?
- From: Jonathan Nieder <email@example.com>
- Date: Wed, 2 May 2012 18:56:48 -0500
- Message-id: <20120502235648.GA504@burratino>
- Mail-followup-to: firstname.lastname@example.org
- In-reply-to: <20120502205554.GA32001@burratino>
- References: <20110224084728.GA13381@elie> <20120502205554.GA32001@burratino>
Jonathan Nieder wrote:
> I'd be happy to talk about work so far, transition plans,
> complications and possible ways forward in a separate message.
This seems like a long shot, but the maintainers of both packages
seemed to like it, so let's give mentioning it a try:
Assuming we go through with the transition, no package in Debian would
use the "node" command. At this point, as far as transition plans go,
it doesn't matter what the "node" command does --- it could have some
other effect entirely.
Now what if we provide both /usr/bin/node and /usr/sbin/node?
As Marco mentioned on debian-devel, there is nothing but our
stubbornness and good sense stopping us from doing that.
- ham radio operators that forgot to update their configuration
would still be able to use /usr/sbin/node. It could print a
helpful message to syslog or stderr to help them migrate.
- on systems with Node.js and not LinuxNode installed,
users of Node.js who are not programmers could use old
scripts that use the "node" command name without trouble.
- on systems with LinuxNode and not Node.js installed,
people used to debugging LinuxNode by typing "node" at the
command line (no, I don't think these people exist; I'm just
saying) could continue to do so. They'd even get a helpful
message to syslog or stderr reminding them to retrain their
- on systems with both LinuxNode and Node.js installed, the
effect of the "node" command would depend on the current
$PATH setting. But using "node" instead of "axnode" or
"nodejs" on such a system is asking for trouble, so no big
Of course this violates the constraints currently documented in
policy, and those constraints exist for good reasons, but I think it's
worth considering as a way to carry out a very smooth transition.