On 12-04-28 at 01:50pm, Joey Hess wrote:
> Jonas Smedegaard wrote:
> > As I understand the current status, it has already on this list been
> > resolved that *both* packages should back off from using the
> > clashing name "node".
> >
> > I also am biased in one direction but shall not say which as I see
> > no benefit at this point in rehashing the discussion: Both packaging
> > "camps" have clearly demonstrated a lack of interest in letting the
> > other use the name "node", which means we must both step off of it.
>
> 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.

Seems the issue is getting rehashing anyway, so let me "reveal" that my
bias is on the side of renaming the ham radio daemon and allow Node.js
to use "node", because a) I have so far failed to locate any sensible
explanation from the ham radio camp why they must keep the name, and b)
Node.js is becoming quite popular and is known generally to use "node"
in its hash-bang.

- Jonas

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

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

On Saturday, April 28, 2012 13:23:21, Russ Allbery wrote:
> Jonas Smedegaard <dr@jones.dk> writes:
> > I also am biased in one direction but shall not say which as I see no
> > benefit at this point in rehashing the discussion: Both packaging
> > "camps" have clearly demonstrated a lack of interest in letting the
> > other use the name "node", which means we must both step off of it.
> >
> > Just today there was progress on the side of Node.js - see bug#650343.
>
> I think that having Node.js not provide the command node would be a real
> disservice to our users (and I say this as someone in neither camp; I've
> never used either program).

In terms of Debian dependencies, there don't seem to be any packages that
depend on the 'node' package from the hamradio section. This makes it tougher
to know what depends on the binary being named 'node'.

A problem with the name 'node' is that it's painful to web search that name to
try to find out what the project is for. :-/ This is another reason not to
like the use of such a generic name.



The hamradio 'node' program looks like it is meant to support several packet
radio protocols, either for a computer acting as a "packet radio router",
"packet radio BBS" (bulletin-board system) or possibly for a "user end-node".
I believe all of these invovle a computer being hooked up to a TNC [Terminal
Node Controller] which is then hooked up to a radio.

For an example of what a TNC looks like, see [1].

Generally packet radio involves low data rate communication. At VHF
frequencies this is generally limited to 1200 baud simplex ("simplex" means
not being able to receive during transmission, whereas "duplex" means being
able to do both simultaneously) -- so the actual throughput is always quite a
bit less than the transmission baud rate. At UHF frequencies due to wider
channels the packet can be a bit faster -- up to 9600 baud. [At SHF and
higher frequencies data rates can be faster

Some TNCs also support other things such as slow scan TV reception, Morse
Code, RTTY, "packet email" (stored in the TNC momory, blinking light to
indicate a message is waiting), packet message forwarding (so that a message
from New York eventually is received in some other part of the country, all
over radio), etc.

Due to low data rates, packet radio isn't as popular today as it was in the
1990's, when telephone modems that were typically in use were also slow. [The
early 90's is when I was doing packet radio.]


[1] http://www.timewave.com/support/PK-232/PK232DSP.html

-- Chris

--
Chris Knadle, KB2IQN
Chris.Knadle@coredump.us
GPG Key: 4096R/0x1E759A726A9FDD74

On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote:
> On 12-04-28 at 01:50pm, Joey Hess wrote:
> > Jonas Smedegaard wrote:
> > > As I understand the current status, it has already on this list been
> > > resolved that *both* packages should back off from using the
> > > clashing name "node".
> > >
> > > I also am biased in one direction but shall not say which as I see
> > > no benefit at this point in rehashing the discussion: Both packaging
> > > "camps" have clearly demonstrated a lack of interest in letting the
> > > other use the name "node", which means we must both step off of it.

Hi all,

I'm not sure if such this solution was already thought of so I have
choosen to present my approach:

A new package named node is created which contains two symlinks
/usr/(s)bin/node, a debconf question, link managing scripts and some
sort of trigger.
Both conflicting packages get a NMU by a neutral member renaming the
node command and adding a dedepency on the new package named node.
When installing only one of the two packages it automatically gets the
node link and everybody is happy.
If both are installed the person is presented a debconf question which
allows him to choose which node* should be the one.

Wouldn't this solve the whole dilemma in a policy compliant and easy
enough fashion that it could be used or what error is there in my idea?

Have a nice sunday
Harald Jenny


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120429135826.GA14307@harald-has.a-little-linux-box.at">http://lists.debian.org/20120429135826.GA14307@harald-has.a-little-linux-box.at

On Apr 29, Harald Jenny <harald@a-little-linux-box.at> wrote:

> Wouldn't this solve the whole dilemma in a policy compliant and easy
> enough fashion that it could be used or what error is there in my idea?
If fixing a real world problem requires so much overhead because of
policy concerns then it looks like the policy needs to be fixed.
Policy is not a religion.

--
ciao,
Marco

On Sun, Apr 29, 2012 at 04:23:25PM +0200, Marco d'Itri wrote:
> On Apr 29, Harald Jenny <harald@a-little-linux-box.at> wrote:
>
> > Wouldn't this solve the whole dilemma in a policy compliant and easy
> > enough fashion that it could be used or what error is there in my idea?
> If fixing a real world problem requires so much overhead because of
> policy concerns then it looks like the policy needs to be fixed.
> Policy is not a religion.
>
> --
> ciao,
> Marco

Agreed but how long would it take to fix the policy vs how long would it
take to produce this package in the face of next stable release?

Kind regards
Harald Jenny


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120429143251.GB14307@harald-has.a-little-linux-box.at">http://lists.debian.org/20120429143251.GB14307@harald-has.a-little-linux-box.at

On Apr 29, Harald Jenny <harald@a-little-linux-box.at> wrote:

> Agreed but how long would it take to fix the policy vs how long would it
> take to produce this package in the face of next stable release?
The current situation does not even cause any practical problems, just
a policy violation.

--
ciao,
Marco

+1 to let Node.js be just "node"


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4F9EA18A.8030109@gmail.com">http://lists.debian.org/4F9EA18A.8030109@gmail.com

* Carl Fürstenberg [2012-04-28 03:31 +0200]:
> There has been an log struggle between the nodejs package and the node
> package, which is still unresolved (bug #611698 for example) And I
> wonder now what the future should look like.

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

Nowadays, the popcon stats for both packages strongly suggest that most
of node's user are users that wanted to install node.js and did not
remove the node package after noticing that it is not what they
expected.

Given that node is a rarely used daemon and that nodejs is a widely used
language, I think that nodejs should get the binary name node; but due
to the non-responsiveness of node's maintainers I think this might be
a case where involving the tech-ctte would help.

node's maintainers don't participate in such discussions in a reasonable
and timely manner, for example the RC bug had no action for months
despite the patch and nobody ever explained what exactly the problem of
a changed binary name for a daemon would be (node can be used
interactively, but it is not supposed to be used that way and those
users that do would be able to set up an alias anyway). The first
answer from one of the uploaders was sent nearly a year after nodesjs'
maintainer asked about this issue on the maintainer's list (back then he
didn't seem to notice that those who answered were unrelated to the node
package). The subject of the -devel thread last year "Is anyone
maintaining (the ham radio tool) node?" speaks for itself.

I assume all of node's uploaders did great work on many ham related
packages, but all that the two uploaders that replied to this issue
during the last two years did related to the node package is that they
also replied to the "Call for debian hamradio developers pool" from
node's actual but now retired maintainer who then added them as
uploaders. Only Hamish, who did not respond to this issue, uploaded
node once in 2005, the others did never do any upload. The responses
from the other two uploaders were essentially "please report a bug"
(although this was already done) by one; and "... then no package should
get the name" and in one mail "this patch needs to be tested by someone
who runs node and nodejs" by the other.


Regards
Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120430230711.GB17150@furrball.stateful.de">http://lists.debian.org/20120430230711.GB17150@furrball.stateful.de

* Carsten Hey [2012-05-01 01:07 +0200]:
> Only Hamish, who did not respond to this issue, uploaded
> node once in 2005,

I need to correct myself, Hamish replied once. In
<20110208230458.GA23497@risingsoftware.com> he wrote:
| I think renaming the node binary to axnode is reasonable and
| consistent with this, but I don't think the nodejs program should be
| using that name either.

Pat replied earlier than I thought, but these earlier replies were
indistinguishable from replies of other people that are not listed in
the uploaders field (i.e., without priorly checking who is listed in
it).


The origin of what the policy suggests to do if there is no consensus is
a mail from Guy Maor <879142cjni.fsf@slip-61-16.ots.utexas.edu>, in
which he writes:
| That's basically a stick to force developers to reach a consensus.

Christian Schwarz uploaded this change later in this month.


I don't think that there ever will be a consensus in all those
discussions without discussing in a reasonable way (which failed in the
past multiple times). Previously to this, asking the VP of Engineering
for a decision was suggested in this thread.


Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120501160354.GZ17599@furrball.stateful.de">http://lists.debian.org/20120501160354.GZ17599@furrball.stateful.de

Carsten Hey <carsten@debian.org> writes:

> The origin of what the policy suggests to do if there is no consensus is
> a mail from Guy Maor <879142cjni.fsf@slip-61-16.ots.utexas.edu>, in
> which he writes:
> | That's basically a stick to force developers to reach a consensus.

> Christian Schwarz uploaded this change later in this month.

> I don't think that there ever will be a consensus in all those
> discussions without discussing in a reasonable way (which failed in the
> past multiple times). Previously to this, asking the VP of Engineering
> for a decision was suggested in this thread.

I have to admit that I'm tempted to change Policy from "if there's no
consensus, rename both of them" to "if there's no consensus, try harder to
reach a consensus, and the technical committee decides in last resort."

Most of the time, renaming both of them isn't the right answer.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sjfjzu8e.fsf@windlord.stanford.edu">http://lists.debian.org/87sjfjzu8e.fsf@windlord.stanford.edu