Patrick Ouellette wrote:
> Earlier when this particular situation was being discussed, someone mentioned
> the generic name "node" was bad for a computer binary.  10-15 years ago it
> was a different landscape.  The node.js folks should probably have given
> more thought to their binary's name given the nature of the computer software
> landscape at the time they created their program.  I can see the logic in
> this argument, and so can support changing *both* binaries.

I think this discussion illustrates why simple non-specific names are
poor choices for both packages and for programs.  Even 10-15 years ago
"node" was already a fairly generic term.  I don't think either
package is completely free of guilt.  Not changing the name now just
pushes the problem further into the future for when there is another
different conflict over that name later.  Or simply pick one to
grandfather in as having been there first.  I think either are
defensible decisions.  It is unfortunate that even when names are
relatively unusual and unique that conflicts sometimes appear anyway.
Such as happened with "git".

Is there a blacklist of names that have previously conflicted and so
have been renamed?  Otherwise, assuming a renaming happens, is there
anything to prevent a new ITP some time in the future from stepping
into the previously conflicted name?  That would be a tragedy for both
of the current packages.

> I recall this situation earlier for the axlisten binary.  Back when I was
> maintaining the ax25-* packages alone, someone complained that listen 
> conflicted with their audio player (I think) with the same binary name.  I
> ...

There are many poor names.  Some like cut and paste have been around
for so long and are so well known that they are not really a problem.
But some are new and just seem like trouble such as "play", and
apparently "listen" and also "open" also comes to mind.  But neither
would I want all programs to be named in such a unique fashion that I
would have to type in "some-specific-name-to-some-program" either.
The balance in the middle isn't trivial.

cul es 73 de kf0uw

Attachment: signature.asc
Description: Digital signature

Pkg-javascript-devel mailing list

Reply via email to