Bug#614907: nodejs/node command conflict: reasons to include the command in each package
(replying to debian-ctte@ only to avoid spamming innocent readers of
debian-hams et al)
Jonathan Nieder wrote:
> I'd be happy to talk about work so far, transition plans,
> complications and possible ways forward in a separate message.
Ok, let's start with what I think is the least interesting question:
who should keep the "node" command?
Drawing from recent discussion:
it's the topic of books,
widespread use independent of the upstream developers, and lots of
articles and Internet documentation with a life of its own. A quick
Google search comes up with tons of indepedent sites telling people to run
programs with "node <script-name>". That makes renaming a much more
From a purely pragmatic POV, how many people are using both packages?
If the answer is zero, and this seems relatively likely, can't we
just add a Conflicts/Breaks and be done with it.
As I understand the current status, it has already on this list been
resolved that *both* packages should back off from using the clashing
No, wait, nodejs:
Just because someone read policy or whatever it was in a way that
requires this King Solomonesque approach to this sort of conflict, does
not actually mean that it makes sense to me, or I hope, to most of us.
It's certianly not the fait accompli you make it out to be.
There is a transition plan and patch for the (ham radio) node in
#614907. Nobody has been able to demonstate any appreciable problems
with renaming it. Indeed, noone has demonstrated any likely reason
for its "node" command to be run directly.
The current situation does not even cause any practical problems, just
a policy violation.
Nah, let's pass the buck. :)
In short I think that there is only one sane solution to this and that
the way to reach this solution is to ask the tech-ctte for a decision.
This is the second thread about this topic on -devel, the first one was
in November 2011. In both threads and in some smaller ones, people
basically claimed things like (incomplete list):
* node is older and nodejs should have checked the binary name
* first come first server
* nodejs is used as node in the shebang line
* my node is more widely used than yours (which node is meant depends
on the year)
* node is a daemon and there it does not matter what name it uses
* one of them should use the binary name node
* none should use the binary name node if there is no consensus
* let the user decide via debconf
* users from either group would complain if they need to use a name
other than node
* policy is wrong, packages should conflict
* conflicts would be wrong
If someone is not paying attention, they will "upgrade" node to axnode (or
whatever) which breaks their system (unknown to them because they were
distracted during the upgrade). They respond to an emergency, only to
find their kit is broken and they have no way to fix it because there is
no internet connectivity.
The emergency communications plan has to allow for malfunctions, but now
they are operating in scramble mode instead of the "comfortable" drilled
and tested mode.
Ham radio operators do this FOR FREE, just like open source software
Changing the ham radio node without a transition plan (most likely a
multi-release plan) is throwing the ham radio people under the bus
The arguments that I understand come down to four points:
0. "node" is an ugly and generic command name. Best to get rid of it.
interface. Programs outside Debian and printed books use it. Not
calling the command "node" will hurt interoperability with the
rest of the world.
---> nodejs or both
2. Renaming "node" is dangerous and confusing. The transition needs
to be carried out carefully, ideally over several releases.
Especially since the release is coming soon.
In particular, using a different command from upstream creates
friction. Some work is needed to patch upstream, too, assuming
upstream agrees with the change.
---> both, I guess?
3. The name "node" was already taken when Node.js (upstream? Debian?)
maintainers tried to use it, and users of other packages should
not suffer for that.
If you don't care about fairness, think about the moral hazard ---
if we let the big guy get away with name conflicts now, won't the
next trendy project be careless about stealing names next time?