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

Bug#614907: tech-ctte: please help maintainers of packages with a "node" command to have a reasonable conversation

* Russ Allbery (rra@debian.org) [120503 01:33]:
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > I'm disappointed to see this is still rumbling on.  There is only one
> > correct solution, and it is this:
> >> In the long term, I would be happiest if both were renamed.
> I won't reiterate the arguments that I've already made on debian-devel,
> but will mention here for those who haven't been following that discussion
> that I think I disagree.  Based on the information that I currently have
> (and this has been changing over the course of the discussion), I think
> Node.js should (eventually, with a suitable transition) have the name
> node, since the use of it in the ham radio package is as an inetd-invoked
> daemon and the renaming there doesn't have much impact.  (It's a system
> interface, but not really a user interface.)
> It's interesting that Fedora has nodejs, and I think we should also
> provide nodejs and encourage people to use that name, but I think it would
> be best for our users to also provide node.

In this case, I think the name the binary is installed as should be
nodejs, not node. (A symlink is a different topic, see below.)

Also, as you said, the ham radio package is (AFAICUI) only used
"internally" (considering a binary run by inittab, inetd etc as
internally), so a step-by-step-transition to a different name
shouldn't be too hard. Independend of whether the nodejs-package
contains a symlink in the end, I think that change should be done
because "node" is a generic name.

Regarding the symlink: I'm currently not convinced how hard it would
be to not set the symlink. Whoever wants it can set it in
/usr/local/bin or ~/bin/ (or via an alias). Especially as this is also
the case in Fedora, I'd tend to also not using an symlink.

> I also think the current Policy suggestion to rename both programs in the
> event of an unreconciled naming conflict is not a very good idea, and
> think it should change to instead list the Technical Committee as the
> decision-maker of last resort.  Renaming both programs is likely to be the
> right move only in cases where both programs are pretty obscure and fairly
> new.

Agreed. Perhaps something like "usually, newcomers should respect the
namespace" wouldn't sound wrong to me (but not as an absolute rule of

Also, the policy should prevent using too generic names (if both
packages rename, the name "node" is free again to be used, and I don't
think that's proper).


Reply to: