[Pkg-javascript-devel] Is anyone maintaining (the ham radio tool) node?

[Patrick Ouellette]

On Wed, Nov 09, 2011 at 08:33:38AM +0000, Philipp Kern wrote:
> 
> On 2011-11-08, Patrick Ouellette <pat at flying-gecko.net> wrote:
> > I hope to avoid any issues with breaking old boxes with the eventual
> > resolution of the issue.
> 
> I don't know what's wrong with Jonathan Nieder's advise in [0] about helping
> users with the conversion automatically.  That's how it's usually done.
> He even provided that patch.

I don't know that his patch will or will not work.  It needs to be tested
by someone who uses the package(s) in question.  He stated he uses neither
the ham radio node nor nodejs.

I note he provided a patch to the ham radio package, but not to the nodejs
package.  I also note the nodejs maintainers were working on a solution
(last updated in February).

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611698

> 
> Who would refer to the node binary as provided by the ham package node
> except for the inetd and the ax25d superservers?  (Serious question.)
> 

I don't think the packagers are in a position to answer this for any particular
installation.  The end user can create any manner of linkage to any package's
binaries.  Certainly we can control what packages require specific binaries
on a system, but we can not control the user.  

In this particular case, the postinst for node calls update-inetd to add an
entry for node.  And marks it as disabled. This is easy enough to change to 
a different binary name.  


> Because as we're providing a whole distribution we could adjust the latter's
> configuration file and ensure that both packages are upgraded (using Breaks,
> for instance).
> 
> > The issue is one of following policy.  Debian policy doesn't allow such a 
> > "resolution" to this issue. Consensus on which must change, or both must
> > change are the only allowed outcomes.
> 
> In this case the two packages at least don't ship the same file.  With the
> current situation you can coinstall the packages and both parts ham and
> nodejs shebangs will keep working.
> 

Provided the programs are being called with complete path names this is true.
If the user is just calling "node" then it depends on the ordering of the
search path.  I'm pretty sure this is something most people want to avoid

> But then policy talks of "filenames" and I don't know if that refers to files
> with a full path or not…  If so, invoking policy as a reason wouldn't help
> here.
> 

Jonathan invoked policy as a reason to change the names, then claimed he 
wanted node.js to retain the binary name node.  You can't have it both ways
in the absence of consensus.  It appears not enough people in the project care
about either package to reach a consensus.

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 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
argued for the ax25-* package and prevailed.  A couple of years later after
I was no longer maintaining the ax25-* packages someone complained again
and the maintainer for the ax25-* packages decided to change the name to
axlisten.


Thanks for your questions and input!

Pat
-- 

Patrick Ouellette                 pat at flying-gecko.net
ne4po (at) arrl (dot) net         Amateur Radio: NE4PO 

What kind of change have you been in the world today?