Bug#614907: node: name conflicts with node.js interpreter

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bug#614907: node: name conflicts with node.js interpreter

Jonathan Nieder
Package: node
Version: 0.3.2-7.1
Severity: serious
Justification: policy §10.1
Tags: upstream

Hi,

Both LinuxNode (package "node") and node.js (package "nodejs") are
designed to be accessed through the command name "node".  There seems
to be no agreement[1][2] in Debian about what should be done with that
name.  Therefore both binaries must be renamed.

John Goerzen provided some useful advice[3]:

| ... resulting in considerable confusion from many people, given that
| much documentation out there refers to call and listen. I, for one,
| was rather puzzled, especially since there is also an ax25_call which
| does something different.
|
| Not saying it was a bad choice, but just that this was what the result
| was. Much existing documentation is confusing to Debian users.
|
| Also, it should be stated that /usr/sbin/node is normally started from
| ax25d, which is somewhat analogous to inetd. It is not normally
| invoked by users (though it could be). Renaming it will break servers
| unless users are well aware.

This says to me:

 - the renaming ought to be documented in README.Debian and NEWS.Debian

 - it would be nice to track down documentation in other packages to
   add a note to, too

 - it would be especially nice to help people update their ax25d.conf.
   Luckily, ax25d.conf is a conffile shipped by ax25-tools, so
   tweaking the version ax25-tools ships should already help (and if
   we want to be especially kind, providing a migration tool to be
   invoked by hand).

 - a migration period in testing/sid (but hopefully not in stable)
   during which node is a script that prints a warning and runs
   ax25_node might be appropriate.

If there is any way I can help, please feel free to ask.

Regards,
Jonathan

[1] http://lists.debian.org/debian-devel/2010/09/msg00465.html
[2] http://lists.debian.org/debian-devel/2011/02/msg00163.html
[3] http://lists.debian.org/debian-devel/2011/02/msg00191.html



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20110224084728.GA13381@elie

Reply | Threaded
Open this post in threaded view
|

Is anyone maintaining (the ham radio tool) node?

Jonathan Nieder
Hi,

In February, I wrote[1]:

> Both LinuxNode (package "node") and node.js (package "nodejs") are
> designed to be accessed through the command name "node".
[...]
> If there is any way I can help, please feel free to ask.

No response from the "node" package maintainers.  My offer still
stands, but I am worried that this is not going to be fixed before the
next release.

So, what next?  Should the node package be orphaned?  Based on popcon,
it seems to have a small but respectable and growing number of users.
Maybe if the current status of the package were more obvious, someone
would start working on it (well, one can hope).

Yours,
Jonathan

[1] http://bugs.debian.org/614907


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111106072651.GA31593@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Patrick Ouellette
On Sun, Nov 06, 2011 at 01:27:42AM -0600, Jonathan Nieder wrote:

>
> Hi,
>
> In February, I wrote[1]:
>
> > Both LinuxNode (package "node") and node.js (package "nodejs") are
> > designed to be accessed through the command name "node".
> [...]
> > If there is any way I can help, please feel free to ask.
>
> No response from the "node" package maintainers.  My offer still
> stands, but I am worried that this is not going to be fixed before the
> next release.
>
> So, what next?  Should the node package be orphaned?  Based on popcon,
> it seems to have a small but respectable and growing number of users.
> Maybe if the current status of the package were more obvious, someone
> would start working on it (well, one can hope).
>
Popcorn is not a definitive measure of a package's use or usefulness to
a group of people.  Not every machine runs popcorn.

Debian maintainers, like all free software maintainers, work on what they
choose to work on for their own reasons and in their own time frame.  Please
do not confuse a lack of updates with a lack of active maintainer(s).  The
upstream AX25 tools have not had much activity and for the most part do what
they are designed to do.

The binary on the ham radio side is not "LinuxNode" in package "node" it is
simply "node" in package "node"

Since you are still concerned with this issue, and neither side has shown a
willingness to change, I would say the time has come for both packages to be
renamed.

Pat (one of the unresponsive ham radio maintainers)
--

Patrick Ouellette                 [hidden email]
ne4po (at) arrl (dot) net         Amateur Radio: NE4PO

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

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Jonathan Nieder
Hi Pat,

Patrick Ouellette wrote:

> The binary on the ham radio side is not "LinuxNode" in package "node" it is
> simply "node" in package "node"
>
> Since you are still concerned with this issue, and neither side has shown a
> willingness to change, I would say the time has come for both packages to be
> renamed.

Just to be clear: both package names are fine --- it's the names of
the binaries that cause trouble.

Being a user of neither package, I'd actually prefer for the name of
the javascript interpreter to stay "node" (sorry!).  It is the
difference between needing to change the configuration of one
superserver and needing to change the shebang line and content of many
scripts.  However, if the only way to include both node and nodejs in
wheezy is for the interpreter binary to be renamed, too, that's ok
with me.  There's currently a release-critical bug against nodejs
about that.

Should the binary on the ham radio side be called ax25-node, or
LinuxNode, or something like that?  Given a proposed name, I would be
happy enough to assume I have your blessing and start sending patches
to the node bug. :)

> Pat (one of the unresponsive ham radio maintainers)

Glad to hear from you, and thanks for your hard work keeping the
amateur radio stack working.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111107032031.GA25810@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Patrick Ouellette-2
On Sun, Nov 06, 2011 at 09:20:31PM -0600, Jonathan Nieder wrote:

>
> Hi Pat,
>
> Patrick Ouellette wrote:
>
> > The binary on the ham radio side is not "LinuxNode" in package "node" it is
> > simply "node" in package "node"
> >
> > Since you are still concerned with this issue, and neither side has shown a
> > willingness to change, I would say the time has come for both packages to be
> > renamed.
>
> Just to be clear: both package names are fine --- it's the names of
> the binaries that cause trouble.
>
> Being a user of neither package, I'd actually prefer for the name of
> the javascript interpreter to stay "node" (sorry!).  It is the
> difference between needing to change the configuration of one
> superserver and needing to change the shebang line and content of many
> scripts.  However, if the only way to include both node and nodejs in
> wheezy is for the interpreter binary to be renamed, too, that's ok
> with me.  There's currently a release-critical bug against nodejs
> about that.

You claim to not use either package, but yet you advocate for the node.js
package to keep the executable name "node" - this is strange to me.

Having a vested interest in the ham radio package retaining the name "node"
and pointing out the history of the ham radio package being in Debian long
before the node.js package, I want the ham radio package to retain the name.

Apparently a consensus has not been reached, or at least not one that you
recognize.  In the event of no consensus, Debian policy calls for *both*
packages to have their binaries renamed.  You even say as much in the bug
report you filed against the node package.

>
> Should the binary on the ham radio side be called ax25-node, or
> LinuxNode, or something like that?  Given a proposed name, I would be
> happy enough to assume I have your blessing and start sending patches
> to the node bug. :)
>

When you assume something..... (if you don't know the rest of the quote,
google it)


Are you a ham radio operator, or do you have another reason to be interested
in the eventual name of the ham radio package? There is currently a bug against
the ham radio package for the binary name conflict.  This is sufficient pending
the outcome of the "what package (if any) may retain the binary name node"
discussions.  When the ham radio maintainers decide on how to implement the
fix, they will.  If you wish to join the ham radio maintainers group, we can
discuss that.

Pat

--

Patrick Ouellette                 [hidden email]
ne4po (at) arrl (dot) net         Amateur Radio: NE4PO

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111107034509.GC16217@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Jonathan Nieder
Patrick Ouellette wrote:

> You claim to not use either package, but yet you advocate for the node.js
> package to keep the executable name "node" - this is strange to me.

Sorry, I must have been unclear.  I was only explaining my preference.
I wasn't lying.  I also said:

>> However, if the only way to include both node and nodejs in
>> wheezy is for the interpreter binary to be renamed, too, that's ok
>> with me.

Indeed, renaming both is what policy (and good sense) requires in the
absence of consensus.  I guess it was foolish of me to imagine that
there could be a discussion resulting in consensus based on something
other than which tool is most important!  (Both tools are obviously
important in their communities.)

[...]
> Are you a ham radio operator, or do you have another reason to be interested
> in the eventual name of the ham radio package?
[...]
> When the ham radio maintainers decide on how to implement the
> fix, they will.

No, I am not a ham radio operator.  I was worried because this
(release-critical) bug had received no response for three quarters of
a year.  I'm glad to hear you say "when" rather than "if" here --- as
far as I can tell, you are saying that I should not be worried and
this bug is not stalled after all.

I am interested in Debian remaining useful for a variety of purposes,
which is why I want to see some proposed fix enter unstable early
enough to shake out problems so wheezy can both include fundamental
tools for ham radio operators and for web developers.

Sorry for the lack of clarity.
Jonathan


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111107053255.GC25810@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Jonathan Nieder
(+cc: [hidden email].  Sorry for the noise.)
Jonathan Nieder wrote:
> Patrick Ouellette wrote:

>> You claim to not use either package, but yet you advocate for the node.js
>> package to keep the executable name "node" - this is strange to me.
>
> Sorry, I must have been unclear.

A few more words of clarification:

It might seems strange that someone using neither package cares about
these bugs.  So here is why I care:

 1. I use Debian.  I do not want it to be broken (one aspect of "broken"
    is the same command having different effects depending on which
    package is installed).  My experience is that for better or worse, if
    the project can't fix a bug like this one, new maintainers of other
    packages in similar situations will take it as an example and
    introduce even more breakage.

 2. Ham radio projects seem neat to me.  Lots of nice people,
    including John Goerzen, are ham radio operators.  It would be nice
    to make sure Debian continues to make their lives pleasant and
    makes my life pleasant if I ever acquire the appropriate hardware.

 3. node.js seems neat to me.  Lots of nice people including Jonas
    Smedegaard use it to program.  I imagine that at some point in the
    future, even if I never start to use the language myself, I might
    find myself running programs using it (like has happened to me
    with ruby already).

I hope you care some small amount about packages you don't currently use,
too. :)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111107055326.GD25810@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Ian Jackson-2
In reply to this post by Jonathan Nieder
Jonathan Nieder writes ("Is anyone maintaining (the ham radio tool) node?"):
> No response from the "node" package maintainers.  My offer still
> stands, but I am worried that this is not going to be fixed before the
> next release.
>
> So, what next?

Our policy says that if consensus cannot be reached, both packages'
binaries should be renamed.  That seems to be the case here.  I agree
with the policy statement that both packages' binaries should be
renamed.  (But then I would say that since I wrote the policy.)

However, we have a process difficulty, which I think may be part of
what is blocking these changes from being made.  Normally a maintainer
would make such a change to their own package.  However, if the
maintainer of package A uploads a rename of their binary to foo-A, the
maintainer of package B now has no more incentive to fix the problem.
A's maintainer leaves themselves open to the maintainer of B "winning"
through B's inaction.

Now I'm not accusing anyone of dishonesty or bad faith, but it's easy
to see how this is not an attractive proposition for A, particularly
given that in Debian we don't have any tradition of forcing people in
B's situation to act and our mechanisms for bypassing an inactive B
are cumbersome and slow (to say the least).


I think the best way to fix this is to prepare both renaming uploads
in advance, and allow either of the two contending maintainers to
upload both packages simultaneously.


So I would suggest that:

  1a. The maintainer of "node" should prepare a new version of the
      package where the "node" binary is called "ax25-node", and
      containing whatever transitional arrrangements etc. they are
      happy with.  (It may be necessary for the maintainers to notify
      each other of their proposed new version numbers, so that the
      package dependencies can be correct.)

      However, the "node" maintainer should not sign the package and
      should not actually upload it.  They should instead put it on a
      public server (not mentors.debian.net, to avoid accidents!) and
      send an email (signed with their Debian key) with the details
      (including the checksum of the .changes) to the bug report and
      the "nodejs" maintainer.

 (1b. If the maintainer of "node" is not a DD or DM, and therefore
      normally needs a sponsor for their own uploads, they should now
      seek and obtain technical review from a sponsor.  The sponsor
      should, if satisfied, send an email to that effect signed with
      their Debian key.)

  1c. The maintainer of "nodejs" should download this package and
      review the handling of the name change.  If the "nodejs"
      maintainer considers that this upload fixes the problem
      according to policy they should say so.

Simultanously:

  2a. Likewise the maintainer of "nodejs" should prepare a version
      of the package where the "node" binary is called "nodejs".

 (2b. Likewise any necessary sponsor review of "nodejs".)

  2c. The maintainer of "node" should review this, as above.

After mutual approval of each package by both maintainers, ie after
each maintainer has said "yes" in step 1c/2c:

  3.  Either maintainer may upload _both_ packages.  (In general this
      would most conveniently be done by the maintainer who is the
      later to give their approval.)  The maintainer doing the
      uploading should upload their own package first.

 (3a. Alternatively, if either of the maintainers is not a DD,
      the may request a sponsor to upload both packages.  The sponsor
      should confirm both approvals as above, and also confirm that
      any necessary sponsor review by a DD took place earlier, but
      need not undertake a technical review.)

  4.  If something goes wrong with this process, which results in only
      one of the packages having its binary renamed in the archive,
      both maintainers agree that the other maintainer may send an NMU
      to fix this to DELAYED-7.

I include the stuff about sponsors, and failure recovery, in case it's
relevant, so that my proposal can be used as a template in future
cases.

Ian.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20151.57412.130027.129313@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Damien Gardner Jnr
In reply to this post by Jonathan Nieder
On 07/11/2011, at 2:20 PM, Jonathan Nieder wrote:
Should the binary on the ham radio side be called ax25-node, or
LinuxNode, or something like that?  Given a proposed name, I would be
happy enough to assume I have your blessing and start sending patches
to the node bug. :)

I have to pop my head up from my lurker-hole here, and say that I'm a more than a little confused, why a 15 year old application should change its name at all?  Even the Node.js wiki makes it clear that the application should be called Node.js 'to disambiguate it from other nodes' - it sounds like the developers are being proactive in notifying users that they picked a name which conflicts with other packages?

I don't know about others, but I'm not overly keen on the idea of reconfiguring machines which were installed last century, because a program which appeared in the last two years has the same name..  If you think about it, node.js is *much* more 'able' to change the name of its binary - it still has an actively developed community!  - I don't know about other folk, but I find it pretty darned hard to find much 'current' documentation about a lot of the older x.25 & bbs stuff I have running on some of my older boxen - one of my BBS packages doesn't even appear in a google search anymore (god help me if the wrapper I setup in 2001 to make it telnet-accessible as well as dial-in, ever breaks ;) )

Although I'm curious why both packages can't just shove a Conflicts: in for each other, and be done with it?  Or just leave it as is, since they're in different directories, provided a nice big must-click-ok dialog comes up during install/upgrade to notify the user of the change?  From the AX.25 side, and probably at least partly from the Node.js side, the users are going to be fairly cluey, if not accomplished hackerers - having multiple binaries of the same name, in different directories in the path is nothing new (hell, we used to rely on it on some of our hosting servers - things like reboot, shutdown, etc were wrappered with scripts in higher-preferenced directories from the PATH, to make sure accidental reboots, shutdowns, rm's etc, couldn't happen, as explicit paths had to be used..   As for scripts etc, well, if you're not specifying the absolute path to any binary you're calling, you're just asking for trouble anyway!

Cheers,

DG

Damien Gardner Jnr
VK2TDG. Dip EE. GradIEAust
[hidden email] -  http://www.rendrag.net/
--
We rode on the winds of the rising storm,
 We ran to the sounds of thunder.
We danced among the lightning bolts,
 and tore the world asunder

Reply | Threaded
Open this post in threaded view
|

Bug#614907: Is anyone maintaining (the ham radio tool) node?

Jonathan Nieder
In reply to this post by Jonathan Nieder
Jaime Robles wrote:

> OK I have found your offer!Send the bugs to the package so the problem can
> be solved :-)

Well, not bugs, but patches.  I imagine they would be something like this:

 1. rename node to ax25-node, and add a compatibility wrapper that
    prints a message and calls ax25-node.  Update inetd.conf to use the
    new command name.

 2. add a NEWS.Debian for node, explaining that the command has been
    renamed

 3. update the default ax25d.conf to use ax25-node instead of node

 4. ax25-tools.postinst: offer to update ax25d.conf to use the new command
    name

 6. remove the 'node' compatibility wrapper

Part 1 might look like this:
---
 INSTALL                     |    8 +-
 Makefile                    |   18 ++-
 debian/NEWS                 |   12 ++
 debian/postinst             |    2 +-
 man/{node.8 => ax25-node.8} |   10 +-
 man/node.8                  |  254 ++++---------------------------------------
 man/node.conf.5             |   20 ++--
 node.sh                     |    8 ++
 8 files changed, 71 insertions(+), 261 deletions(-)
 create mode 100644 debian/NEWS
 rename man/{node.8 => ax25-node.8} (97%)
 rewrite man/node.8 (98%)
 create mode 100644 node.sh

diff --git a/INSTALL b/INSTALL
index 26aac9a3..40ca78fa 100644
--- a/INSTALL
+++ b/INSTALL
@@ -37,23 +37,23 @@ these files. The AX25-HOWTO is a must read also.
 
 Node is intended to be called from ax25d or inetd. It doesn't need
 any command line arguments but there is one to support incoming
-compressed connects. See the node(8) manual page.
+compressed connects. See the ax25-node(8) manual page.
 
 To run LinuxNode from ax25d, /etc/ax25/ax25d.conf should have something
 like this in it:
 
   # AX.25
   [OH2BNS VIA 144]
-  default  * * * * * *  -    root  /usr/bin/node  node
+  default  * * * * * *  -    root  /usr/bin/ax25-node  ax25-node
 
   # NETROM
   <netrom>
-  default  * * * * * *  -    root  /usr/bin/node  node
+  default  * * * * * *  -    root  /usr/bin/ax25-node  ax25-node
 
 /etc/inetd.conf could have something like this in it:
 
   # Set up LinuxNode to listen at telnet port
-  telnet  stream  tcp     nowait  root    /usr/bin/node     node
+  telnet  stream  tcp     nowait  root    /usr/bin/ax25-node     ax25-node
 
 Note that LinuxNode should always be run as root. Otherwise outgoing
 connects won't work. Also ping needs a raw socket which requires root
diff --git a/Makefile b/Makefile
index 299b65b3..75caf6dd 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-all: nodeusers node
+all: nodeusers ax25-node node
 
 CC = gcc
 LD = gcc
@@ -23,13 +23,12 @@ NODEUSERS_OBJS = $(NODEUSERS_SRC:.c=.o)
 install: installbin installconf installman installhelp
  install -m 755    -o root -g root -d $(prefix)$(VAR_DIR)/node
  install -m 644    -o root -g root etc/loggedin $(prefix)$(VAR_DIR)/node
- @rm -f /usr/bin/node
- @rm -f /usr/bin/nodeusers
 
 installbin: all
  install -m 755     -o root -g root -d $(prefix)$(SBIN_DIR)
- install -m 4755 -s -o root -g root node $(prefix)$(SBIN_DIR)
+ install -m 4755 -s -o root -g root ax25-node $(prefix)$(SBIN_DIR)
  install -m 755  -s -o root -g root nodeusers $(prefix)$(SBIN_DIR)
+ install -m 755     -o root -g root node          $(prefix)$(SBIN_DIR)
 
 installhelp:
  install -m 755    -o root -g root -d $(prefix)$(LIB_DIR)/ax25/node/help
@@ -48,6 +47,7 @@ installman:
  install -m 644    -o bin -g bin man/node.conf.5  $(prefix)$(MAN_DIR)/man5
  install -m 644    -o bin -g bin man/node.perms.5 $(prefix)$(MAN_DIR)/man5
  install -m 755  -o root -g root -d             $(prefix)$(MAN_DIR)/man8
+ install -m 644    -o bin -g bin man/ax25-node.8  $(prefix)$(MAN_DIR)/man8
  install -m 644    -o bin -g bin man/node.8       $(prefix)$(MAN_DIR)/man8
 
 clean:
@@ -57,17 +57,21 @@ clean:
 
 distclean: clean
  rm -f .depend Makefile.include config.h
- rm -f node nodeusers
+ rm -f ax25-node nodeusers node+ node
 
 depend:
  $(CC) $(CFLAGS) -M $(COMMON_SRC) $(NODE_SRC) $(NODEUSERS_SRC) > .depend
 
-node: $(COMMON_OBJS) $(NODE_OBJS)
- $(LD) $(LDFLAGS) -o node $(COMMON_OBJS) $(NODE_OBJS) $(LIBS) $(ZLIB)
+ax25-node: $(COMMON_OBJS) $(NODE_OBJS)
+ $(LD) $(LDFLAGS) -o ax25-node $(COMMON_OBJS) $(NODE_OBJS) $(LIBS) $(ZLIB)
 
 nodeusers: $(COMMON_OBJS) $(NODEUSERS_OBJS)
  $(LD) $(LDFLAGS) -o nodeusers $(COMMON_OBJS) $(NODEUSERS_OBJS) $(LIBS) $(ZLIB)
 
+node: node.sh
+ cp node.sh node+
+ mv node+ node
+
 ifeq (.depend,$(wildcard .depend))
 include .depend
 endif
diff --git a/debian/NEWS b/debian/NEWS
new file mode 100644
index 00000000..52a8da7c
--- /dev/null
+++ b/debian/NEWS
@@ -0,0 +1,12 @@
+node (0.3.2-8) experimental; urgency=low
+
+  The /usr/sbin/node daemon has been renamed to /usr/sbin/ax25-node.
+  The inetd configuration is automatically updated, but other
+  configuration (including ax25d) is not yet.
+
+  Please update your scripts to use the new name.
+
+  A /usr/sbin/node wrapper has been included to avoid breaking
+  working setups in the short term.
+
+ -- Jonathan Nieder <[hidden email]>  Tue, 08 Nov 2011 12:34:43 -0600
diff --git a/debian/postinst b/debian/postinst
index 888d6394..c96ba911 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -25,7 +25,7 @@ set -e
 case "$1" in
     install|upgrade|configure)
         update-inetd --add \
-        "bbs\tstream\ttcp\twait\troot\t/usr/sbin/node\tnode"
+        "bbs\tstream\ttcp\twait\troot\t/usr/sbin/ax25-node\tax25-node"
         update-inetd --disable bbs
     ;;
 
diff --git a/man/node.8 b/man/ax25-node.8
similarity index 97%
rename from man/node.8
rename to man/ax25-node.8
index 0a7c1ca2..b12b9282 100644
--- a/man/node.8
+++ b/man/ax25-node.8
@@ -1,11 +1,11 @@
-.TH NODE 8 "16 June 1999" Linux "Linux System Managers Manual"
+.TH AX25-NODE 8 "16 June 1999" Linux "Linux System Managers Manual"
 .SH NAME
-node \- Node front end for AX.25, NET/ROM, Rose and TCP
+ax25\-node \- Node front end for AX.25, NET/ROM, Rose and TCP
 .SH SYNOPSIS
-.B node [-c]
+.B ax25\-node [-c]
 .SH DESCRIPTION
 .LP
-.B Node
+.B ax25\-node
 is a simple node front end, modelled after the node shells of TheNet
 and G8BPQ nodes.
 .SH OPTIONS
@@ -22,7 +22,7 @@ At the moment I know only two implementations compatible with this
 compression method, namely LinuxNode and Clussed.
 .SH NODE COMMANDS
 The following commands are supported for users of
-.B node:
+.B ax25\-node:
 .TP 14
 .BI ?
 Give short list of available commands.
diff --git a/man/node.8 b/man/node.8
dissimilarity index 98%
index 0a7c1ca2..7e160b2e 100644
--- a/man/node.8
+++ b/man/node.8
@@ -1,234 +1,20 @@
-.TH NODE 8 "16 June 1999" Linux "Linux System Managers Manual"
-.SH NAME
-node \- Node front end for AX.25, NET/ROM, Rose and TCP
-.SH SYNOPSIS
-.B node [-c]
-.SH DESCRIPTION
-.LP
-.B Node
-is a simple node front end, modelled after the node shells of TheNet
-and G8BPQ nodes.
-.SH OPTIONS
-.TP 14
-.BI \-c
-Enable compression. With this option it is assumed that the incoming
-call is using Zlib based compression (modified Lempel-Ziv 1977).
-Currently no negotiation is done so the
-caller must be aware of this. You probably want to set up a separate
-AX.25, NET/ROM or ROSE callsign in ax25d.conf or a separate TCP port
-in inetd.conf to listen to compressed connects.
-.sp 1
-At the moment I know only two implementations compatible with this
-compression method, namely LinuxNode and Clussed.
-.SH NODE COMMANDS
-The following commands are supported for users of
-.B node:
-.TP 14
-.BI ?
-Give short list of available commands.
-.TP 14
-.BI Bye
-Disconnect user from the node.
-.TP 14
-.BI "Connect <port> <call> [via <call1> ...] [d|s]  For AX.25"
-.TP 14
-.BI "Connect <call | alias> [d|s]                   For NET/ROM"
-.TP 14
-.BI "Connect <call> <address> [<digi>] [d|s]        For ROSE"
-.sp 1
-Initiate an AX.25, NET/ROM or ROSE connection to a remote host.
-If only one argument is supplied then the connection is assumed to be a
-NET/ROM connection and the argument specifies the callsign of alias of a
-NET/ROM node. If more than one argument is supplied and the second parameter
-is composed of numeric characters only then the connection is assumed to be
-a ROSE connection. Any other combination is assumed to be an AX.25 connection
-with the first argument being the AX25 port to use for the connection.
-.sp
-For a ROSE connection the <address> part must be exactly six or ten digits.
-If only six digits are supplied, the DNIC (first four digits) default to the
-local DNIC. The local DNIC is assumed to be that of the first configured
-Rose port in /etc/ax25/rsports.
-.sp
-The user may optionally supply as the last argument a single character
-which modifies the default behaviour on disconnection of the connection.
-If a single `s' is entered as the last argument, then when the remote host
-disconnects you will be returned to this node. If a single `d' is entered as
-the last argument, you will be disconnected from this node too. The Default
-behaviour (neither `s' nor `d' entered) is configured in the node configuration
-file and depends on the sysop preference.
-.TP 14
-.BI "Escape [<escape string>]"
-Override the sysop configured default escape character setting. If the Escape
-command is given without an argument then the current escape character setting
-is returned to the user. The escape string may be specified using any of the
-well known codings:
-.IP
-.BI "<char>"
-to enter the escape character in its binary form.
-.IP
-.BI "^C"
-to enter the escape character as a control character value.
-.IP
-.BI "NNN"
-to set the escape character to a Decimal value.
-.IP
-.BI "0xNN"
-to set the escape character to a HexaDecimal value.
-.IP
-.BI "0NNN"
-to set the escape character to an Octal value.
-.IP
-.BI "off"
-to disable the escape character.
-.TP 14
-.BI "Finger [<username>][@<hostname>]"
-Retrieve information about users of a system. If the user
-name is omitted, shows the users currently logged on the
-host. If the hostname is omitted, defaults to the local host.
-.TP 14
-.BI "Help [<command>]"
-Give help for the specified command or this text if no
-command is specified. Commands can not be abbreviated.
-Use the "?" command to retrieve a list of available commands.
-.TP 14
-.BI "HOst <hostname> | <ip address>"
-Give the Domain Name Service host name information about <hostname> or
-<ip address>.
-.TP 14
-.BI Info
-Display the version information and the contents of the
-/etc/ax25/node.info file, which should describe any aspects
-of your system that you would like to brag about.
-.TP 14
-.BI "Links [* | <call>]"
-Give a list of active AX.25 connections to and from the local host.
-With an optional argument * list also AX.25 sockets in state listening.
-A callsign as argument gives a list of all connections with <call> as
-source or destination address.
-.TP 14
-.BI "Mheard <portname>"
-Give a list of heard AX.25 stations on the specified port.
-.TP 14
-.BI "NLinks"
-Give a list of active NET/ROM connections to and from the local host.
-.TP 14
-.BI "Nodes [* | <node>]"
-Show the NET/ROM node table of the local host. The nodes on this
-list can be reached using the Connect command without knowing the
-actual network path used (assuming the network is OK).
-.sp
-The optional argument '*' toggles verbose mode, showing the
-Obsolescence counter, relative path quality and the port and
-neighbour node used to reach each node. You can also specify
-a node callsign to get the verbose information for a single node.
-In that case a "which" field that tells what route the kernel
-will use to reach the node is also shown.
-.TP 14
-.BI Ports
-Show the available AX.25 ports. Shown are the port name and a short
-description for the port. The port name is used when using the Connect
-command to connect to an user or service not running NET/ROM (eg. not
-visible in the Nodes list).
-.TP 14
-.BI "PIng <host> [<size>]"
-Check if a host can be reached trough the network by sending
-an ICMP Echo Request packet to the host and waiting for it to
-reply. If a reply is received the round-trip-time (RTT)
-between the local and remote hosts is shown.
-.sp
-If an optional length is specified the data portion of the
-packet is filled with length number of bytes.
-.TP 14
-.BI Routes
-Show the NET/ROM neighbour table of the local host (ie. the nodes
-which the local node directly talks with). These nodes are used
-to reach the other nodes on the node table.
-.TP 14
-.BI Status
-Give some more or less useful information about the system.
-.TP 14
-.BI "Telnet <host> [<port>] [<string>] [d|s]"
-Initiate a telnet session to a remote host using TCP/IP.
-By default, the telnet command connects to the TCP port 23
-(allocated for telnet). You can specify another TCP port or
-a TCP port name.
-.sp
-If an optional third argument <string> is given, that string, followed
-by a CRLF is sent to the remote host right after the connection is
-established. This is mainly useful for command aliases.
-.sp
-If a single `s' is entered as the last parameter, then when
-the remote host disconnects you will be returned to this node.
-If a single `d' is entered as the last parameter, you will
-be disconnected from this node too. Default behaviour (neither
-`s' nor `d' entered) depends on sysop configuration.
-.TP 14
-.BI "TAlk <user> <message>"
-Send a message to another user of the node. The user
-in question must be in idle state (ie. not connected/connecting
-anywhere or running a program).
-.sp
-If the user has an SSID other than zero, the SSID must be
-specified. If multiple users are logged in with the same
-callsign/SSID pair, those who are in idle state, get the message.
-.TP 14
-.BI Users
-Show a list of users currently connected to the local node,
-where the users are coming from, and what are they doing at the
-moment.
-.TP 14
-.BI "ZConnect"
-Initiate a compressed AX.25, NET/ROM or ROSE connection. The command
-arguments are the same as in
-.B "Connect"
-command. Note that the other end must be expecting a compressed
-connection (a LinuxNode started with the -c command line option).
-No negotiation of compression is done.
-.TP 14
-.BI "ZTelnet"
-Initiate a compressed telnet session. The command
-arguments are the same as in
-.B "Telnet"
-command. Note that the other end must be expecting a compressed
-connection (a LinuxNode started with the -c command line option).
-No negotiation of compression is done.
-.SH FILES
-.LP
-.TP 5
-.B /etc/ax25/node.conf
-LinuxNode configuration file.
-.br
-.TP 5
-.B /etc/ax25/node.perms
-LinuxNode permissions file.
-.br
-.TP 5
-.B /etc/ax25/node.motd
-LinuxNode message of the day file.
-.br
-.TP 5
-.B /etc/ax25/node.info
-The response to the 'info' command.  
-This file should be edited to reflect the local configuration.
-.br
-.TP 5
-.B /var/ax25/node/loggedin
-Database of current users.
-.br
-.TP 5
-.B /var/ax25/mheard/mheard.dat
-Information about AX.25 stations heard.
-.br
-.TP 5
-.B /usr/lib/ax25/node/help/*.hlp
-The online help files.
-.SH "SEE ALSO"
-.BR node.conf (5),
-.BR node.perms (5),
-.BR axports (5),
-.BR ax25d (8),
-.BR mheardd (8).
-.SH AUTHOR
-Tomi Manninen OH2BNS <[hidden email]>
-.br
-Alan Cox GW4PTS <[hidden email]>
+.TH NODE 8 "8 November 2011" Linux "Linux System Managers Manual"
+.SH NAME
+node \- compatibility wrapper for ax25\-node
+.SH SYNOPSIS
+.B node [args]
+.SH DESCRIPTION
+.PP
+.B ax25\-node
+is a simple node front end, modelled after the node shells of TheNet
+and G8BPQ nodes.
+It previously was named
+.B node
+but it has been given a less generic name so scripts can reliably
+refer to the right program.
+The
+.B node
+command prints a warning and then calls
+.BR ax25\-node .
+.SH "SEE ALSO"
+.BR ax25-node (8)
diff --git a/man/node.conf.5 b/man/node.conf.5
index 1b4bad72..daf18fc7 100644
--- a/man/node.conf.5
+++ b/man/node.conf.5
@@ -33,7 +33,7 @@ to use double quotes and escape the percent sign with a backslash (eg. \\%1)
 .B ConnTimeout <timeout>
 When user is connected to another system via this system and the
 connection is idle (no data flowing in either direction) for <timeout>
-seconds the connection is dropped and user disconnected from node.
+seconds the connection is dropped and user disconnected from the node.
 Default is 3600 seconds
 (1 hour).
 .TP 14
@@ -66,14 +66,14 @@ Note that the escape mechanism breaks 8-bit transparency of LinuxNode
 and you should either disable it or set the no-escape flag in node.perms
 for the forwarding stations if (compressed) forward is run trough
 LinuxNode. Also the Escape user command can be used in a forward script
-to disable the escape (see node(8)).
+to disable the escape (see ax25\-node(8)).
 .TP 14
 .B ExtCmd <NAme> <flags> <uid> <exec> <args...>
 Sets up an external command.
 .RS
 .TP 10
 .B NAme
-This is the name under which the command appears at nodes command list.
+This is the name under which the command appears at the node's command list.
 The number of uppercase characters at the beginning of <NAme> specifies
 how much the user may abbreviate the command.
 The uppercase part should be long enough to separate the command
@@ -87,11 +87,11 @@ command is executed. Currently two flags are implemented:
 .RS
 .TP 5
 .B 1
-Run command through pipe. Without this flag node just fork()s and exec()s
+Run command through pipe. Without this flag, ax25\-node just fork()s and exec()s
 the specified command and then waits for it to terminate. The command must
 it self be aware about the underlying protocol. It must handle packetising
-and any end of line conversions. With this flag however node sets up a pipe
-between it self and the command and handles packetising and end of line
+and any end of line conversions. With this flag, however, ax25\-node sets up
+a pipe between itself and the command and handles packetising and end of line
 conversions for it.
 .TP 5
 .B 2
@@ -128,7 +128,7 @@ login and in the node welcome message.
 .TP 14
 .B IdleTimeout <timeout>
 After <timeout> seconds of inactivity while waiting for a command user
-is disconnected from node. Default is 900 seconds (15 mins).
+is disconnected from the node. Default is 900 seconds (15 mins).
 .TP 14
 .B LocalNet <network>
 Defines a "local" network. Users telneting from hosts in this network
@@ -138,7 +138,7 @@ network and a number of significant bits separated by a slash. Note
 that 127.0.0.0/8 (loopback net) is also considered "local" by default.
 .TP 14
 .B LogLevel <loglevel>
-Specifies what node should log. The available levels are:
+Specifies what ax25\-node should log. The available levels are:
 .RS
 .TP 5
 .B 0
@@ -157,7 +157,7 @@ Default is to log only critical errors.
 .RE
 .TP 14
 .B NodeId <id>
-This is the id that is shown in every message from node. Default
+This is the id that is shown in every message from ax25\-node. Default
 is "LinuxNode}".
 .TP 14
 .B NodePrompt <prompt>
@@ -318,7 +318,7 @@ Anything else after a % is substituted with a %.
 .LP
 /etc/ax25/node.conf
 .SH "SEE ALSO"
-.BR node (8),
+.BR ax25\-node (8),
 .BR node.perms (5),
 .BR axports (5),
 .BR ax25 (4).
diff --git a/node.sh b/node.sh
new file mode 100644
index 00000000..a08dafb3
--- /dev/null
+++ b/node.sh
@@ -0,0 +1,8 @@
+#!/bin/sh
+echo >&2 'To avoid breaking scripts that use other commands'
+echo >&2 'named "node", the node(8) program has been renamed'
+echo >&2 'to ax25-node(8).'
+echo >&2
+echo >&2 'Please update your scripts.'
+
+exec ax25-node "$@"
--
1.7.8.rc1




--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111108184209.GA22063@...

Reply | Threaded
Open this post in threaded view
|

Resolve namce conflise with node and nodejs [was Re: Is anyone maintaining (the ham radio tool) node?]

Patrick Ouellette
In reply to this post by Ian Jackson-2
Where is the voice of the nodejs maintainers in this?  They are
listed as:

Debian Javascript Maintainers
Jérémy Lal
Dave Beckett
Jonas Smedegaard


--

Patrick Ouellette                 [hidden email]
ne4po (at) arrl (dot) net         Amateur Radio: NE4PO

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

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Patrick Ouellette-2
In reply to this post by Damien Gardner Jnr
On Tue, Nov 08, 2011 at 07:16:35AM +1100, Damien Gardner Jnr wrote:
>
> I have to pop my head up from my lurker-hole here, and say that I'm a more than a little confused, why a 15 year old application should change its name at all?  Even the Node.js wiki makes it clear that the application should be called Node.js 'to disambiguate it from other nodes' - it sounds like the developers are being proactive in notifying users that they picked a name which conflicts with other packages?
>

You would think there would be some weight given to the length of time a
binary has been in the project, but there is not.  First come, first served
does not apply according to Debian Policy.

> I don't know about others, but I'm not overly keen on the idea of reconfiguring machines which were installed last century, because a program which appeared in the last two years has the same name..  If you think about it, node.js is *much* more 'able' to change the name of its binary - it still has an actively developed community!  - I don't know about other folk, but I find it pretty darned hard to find much 'current' documentation about a lot of the older x.25 & bbs stuff I have running on some of my older boxen - one of my BBS packages doesn't even appear in a google search anymore (god help me if the wrapper I setup in 2001 to make it telnet-accessible as well as dial-in, ever breaks ;) )

I hope to avoid any issues with breaking old boxes with the eventual
resolution of the issue.

>
> Although I'm curious why both packages can't just shove a Conflicts: in for each other, and be done with it?  Or just leave it as is, since they're in different directories, provided a nice big must-click-ok dialog comes up during install/upgrade to notify the user of the change?  From the AX.25 side, and probably at least partly from the Node.js side, the users are going to be fairly cluey, if not accomplished hackerers - having multiple binaries of the same name, in different directories in the path is nothing new (hell, we used to rely on it on some of our hosting servers - things like reboot, shutdown, etc were wrappered with scripts in higher-preferenced directories from the PATH, to make sure accidental reboots, shutdowns, rm's etc, couldn't happen, as explicit paths had to be used..   As for scripts etc, well, if you're not specifying the absolute path to any binary you're calling, you're just asking for trouble anyway!
>

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.

73,

Pat

--

Patrick Ouellette                 [hidden email]
ne4po (at) arrl (dot) net         Amateur Radio: NE4PO

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111108194814.GD30829@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Philipp Kern-4
On 2011-11-08, Patrick Ouellette <[hidden email]> 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.

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

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.

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.

Kind regards
Philipp Kern

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614907


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/slrnjbken2.3js.trash@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Patrick Ouellette-2
On Wed, Nov 09, 2011 at 08:33:38AM +0000, Philipp Kern wrote:
>
> On 2011-11-08, Patrick Ouellette <[hidden email]> 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                 [hidden email]
ne4po (at) arrl (dot) net         Amateur Radio: NE4PO

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111109151610.GA23730@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Bob Proulx
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.

Bob
cul es 73 de kf0uw

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Jonas Smedegaard
In reply to this post by Philipp Kern-4
On 11-11-09 at 08:33am, Philipp Kern wrote:

> On 2011-11-08, Patrick Ouellette <[hidden email]> 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.
>
> Who would refer to the node binary as provided by the ham package node
> except for the inetd and the ax25d superservers?  (Serious question.)
Did anyone address above question already?


Regards,

 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Joey Hess
Jonas Smedegaard wrote:
> > Who would refer to the node binary as provided by the ham package node
> > except for the inetd and the ax25d superservers?  (Serious question.)
>
> Did anyone address above question already?

One user claimed it would inconvenience users, but provided no supporting
details about why a user would run it manually.
http://lists.debian.org/debian-hams/2010/08/msg00032.html
The package's own documentation states "Node is intended to be called from
ax25d or inetd."

A similar case with a large userbase is the syslog daemon. Debian used
to ship standard with a /usr/sbin/syslogd. Then it was replaced with a
/usr/sbin/rsyslog, from a different package. Since rsyslog is Priority
important, it gets installed automatically, and this removes sysklogd;
you can verify this happened to most users on [1]. However, we have
not lost any sleep over users who might have something that ran
/usr/sbin/syslogd directly, and I've never seen this inconvenience a
single user.

I don't know if there's any reason users would be more likely to run
node manually than syslogd manually. Even if there is, the vast
difference in userbases (multiple orders of magnitude) suggests it's
unlikely to inconvenience many users. Probably this case is sufficiently
edge that a NEWS file would do.

--
see shy jo

[1] http://qa.debian.org/popcon-graph.php?packages=sysklogd+rsyslog&show_installed=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Patrick Ouellette
On Wed, Nov 16, 2011 at 04:04:36PM -0400, Joey Hess wrote:

>
> One user claimed it would inconvenience users, but provided no supporting
> details about why a user would run it manually.
> http://lists.debian.org/debian-hams/2010/08/msg00032.html
> The package's own documentation states "Node is intended to be called from
> ax25d or inetd."
>
> A similar case with a large userbase is the syslog daemon. Debian used
> to ship standard with a /usr/sbin/syslogd. Then it was replaced with a
> /usr/sbin/rsyslog, from a different package. Since rsyslog is Priority
> important, it gets installed automatically, and this removes sysklogd;
> you can verify this happened to most users on [1]. However, we have
> not lost any sleep over users who might have something that ran
> /usr/sbin/syslogd directly, and I've never seen this inconvenience a
> single user.
>
> I don't know if there's any reason users would be more likely to run
> node manually than syslogd manually. Even if there is, the vast
> difference in userbases (multiple orders of magnitude) suggests it's
> unlikely to inconvenience many users. Probably this case is sufficiently
> edge that a NEWS file would do.
>

The syslog case does not apply since the *standard* syslog was changed
at the distribution level and another package *provides* the same
functionality.  Users could, if the old syslog package is still in the
archive, install the old syslog as an alternative.


nodejs *only* exists in unstable.  A name change in unstable should be
less disruptive because it is, well - unstable.

Pat

--

Patrick Ouellette                 [hidden email]
ne4po (at) arrl (dot) net         Amateur Radio: NE4PO

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111116203827.GA29795@...

Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Joey Hess
Patrick Ouellette wrote:
> The syslog case does not apply since the *standard* syslog was changed
> at the distribution level and another package *provides* the same
> functionality.  Users could, if the old syslog package is still in the
> archive, install the old syslog as an alternative.

Sure, or they could not notice the syslog change in the rest of the
upgrade noise, and have anything that depended on the name break --
but nobody has complained about that happening.

Either

a) None or a very small number of users are affected by the name change
   of a daemon.
b) Users are affected, but all have no problem with fixing their system.
   (By either changing it to use the new name, or installing a package,
   makes little difference.)
c) All users are so careful during upgrades that anyone affected
   noticed the change and did not let it happen. If you think this
   is the case, I have a debian-user list to sell you. ;-)

--
see shy jo

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is anyone maintaining (the ham radio tool) node?

Damien Gardner Jnr
In reply to this post by Joey Hess
On 17/11/2011, at 7:04 AM, Joey Hess wrote:
> A similar case with a large userbase is the syslog daemon. Debian used
> to ship standard with a /usr/sbin/syslogd. Then it was replaced with a
> /usr/sbin/rsyslog, from a different package. Since rsyslog is Priority
> important, it gets installed automatically, and this removes sysklogd;
> you can verify this happened to most users on [1]. However, we have
> not lost any sleep over users who might have something that ran
> /usr/sbin/syslogd directly, and I've never seen this inconvenience a
> single user.

Yep, and what an epic clusterf*** that is :(  I have a number of clients who have a mix of debian lenny and squeeze, and ubuntu 8 and 10 LTS boxes  - some newly installed, some upgraded, etc etc, and maintaining scripts to check whether a server is running sysklogd or rsyslog, while doing automated config pushes and syslog restarts for logfile archival, etc has been a fairly serious headache.

--DG


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/19AA06CA-6B10-4538-BF61-6BF105677EBB@...

12