Patrick Ouellette <pouelle@debian.org> writes:
> On Fri, Apr 27, 2012 at 08:26:47PM -0700, Russ Allbery wrote:

>> Indeed, and I'm very grateful for that. But realistically that was
>> also a lot easier than renaming Node.js's interpreter, and I think the
>> CITI folks did actually know that was coming. The conflict had already
>> been pointed out in the Kerberos community and had been discussed prior
>> to it coming up here. But more significantly that library was
>> essentially used only by NFS, so only a few clients had to change and
>> the renaming was fairly straightforward.

> The Node.js developer KNEW there were other binaries named node, and
> just went on as if it did not matter. Check the development
> history/blog.

The important part is the last sentence: changing the name was fairly
easy. Also, upstream was willing to change it, which in this case I doubt
is the case (although we can certainly ask).

>> Node.js is at this point another matter; it's the topic of books,
>> widespread use independent of the upstream developers, and lots of
>> articles and Internet documentation with a life of its own. A quick
>> Google search comes up with tons of indepedent sites telling people to
>> run programs with "node <script-name>". That makes renaming a much
>> more difficult prospect.

> And the ham radio binary is the subject of sections of how-to's and
> books on amateur radio. It also has "a life of it's own" in the ham
> radio community.

That community is much smaller, and the binary isn't invoked directly by
users, which makes the impact fairly minimal in practice.

You aren't going to get any argument that the Node.js upstream did
something that was at the least rude. But we have no control over that,
unfortunately. We have to live with the consequences, and I think
usability for our users is more important than fairness if they come
directly in conflict, which I think they are in this case.

> If a binary's name is simply a matter of a popularity contest in Debian,
> at some point every name may be made to change.

I think that assertion is unsupported. We don't encounter situations like
this that frequently. We will continue to encounter them, but I think
we're talking about a case every year or two.

--
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: 877gwvwohd.fsf@windlord.stanford.edu">http://lists.debian.org/877gwvwohd.fsf@windlord.stanford.edu

Patrick Ouellette <pouelle@debian.org> writes:
> On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote:

>> Node.js is becoming quite popular and is known generally to use "node"
>> in its hash-bang.

> Seriously? People are writing scripts that start
> #!node

The #! part is really not the issue, since the two packages don't conflict
there (the ham radio one is in /usr/sbin).

However, Googling for Node.js tutorials and documentation actually reveal
that people usually *don't* use #!, which would avoid the conflict, and
instead run "node <file>". Which means when both packages are installed,
which node they get depends on what their PATH looks like, which is the
sort of conflict that we try to avoid.

--
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: 87k40vv8sl.fsf@windlord.stanford.edu">http://lists.debian.org/87k40vv8sl.fsf@windlord.stanford.edu

* Patrick Ouellette [2012-05-01 16:55 -0400]:
> I was under the impression that neither package was going to move forward with
> a binary named "node"

Some proposed this, some agreed, others did not.

In the just reported bug #671120 I wrote regarding this neither package
should get the name part of the policy:
| The common reading of the according section does neither match what
| seems to be the original intention [1] nor my common sense.
|
| [1] http://lists.debian.org/<879142cjni.fsf@slip-61-16.ots.utexas.edu>


> The proposal was made for a transition plan to be made then the nodejs
> person quit talking/posting.

Ian's proposal was as far as I understood it when reading it basically
rolling a dice and I hope that I either misread it or that it was meant
as a joke.


If the node package needs to rename the binary it obviously needs a new
name Hamish suggested axnode once, the patch lying in the BTS uses
ax25-node. Do you have any preference in case it is needed?


Thanks for caring about 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: 20120501223105.GB14966@furrball.stateful.de">http://lists.debian.org/20120501223105.GB14966@furrball.stateful.de

On Tue, May 01, 2012 at 03:24:58PM -0700, Russ Allbery wrote:
> Date: Tue, 01 May 2012 15:24:58 -0700
> From: Russ Allbery <rra@debian.org>
> Subject: Re: [Pkg-javascript-devel] Node.js and it's future in debian
> To: debian-devel@lists.debian.org
>
> Patrick Ouellette <pouelle@debian.org> writes:
> > On Sat, Apr 28, 2012 at 08:39:41PM +0200, Jonas Smedegaard wrote:
>
> >> Node.js is becoming quite popular and is known generally to use "node"
> >> in its hash-bang.
>
> > Seriously? People are writing scripts that start
> > #!node
>
> The #! part is really not the issue, since the two packages don't conflict
> there (the ham radio one is in /usr/sbin).
>

Of course the #! line is not the issue. The issue is two upstream maintainers
separated by years and miles selected the same generic name for their binary
file. Compounding the issue, some Debian Maintainer seeking to better the
project by packaging additional software for the project failed to perform
"due diligence" in researching if any of the binary names from the proposed
new package were already in use. Having packaged the software and uploaded
it, someone noticed the issue and started us down the path we are on.

> However, Googling for Node.js tutorials and documentation actually reveal
> that people usually *don't* use #!, which would avoid the conflict, and
> instead run "node <file>". Which means when both packages are installed,
> which node they get depends on what their PATH looks like, which is the
> sort of conflict that we try to avoid.
>

So Google says most people run the files interactively from the command
line, almost never from scripts?

Be careful using search engine results to support your position. You
can usually skew the results depending on which search engine you use
and how you word the search.

Do you still do things (especially repetitive things) the way you learned
in the tutorial/documentation? Do you automate processes with shell scripts,
or type the command each time?


Pat


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120502031200.GB18417@flying-gecko.net">http://lists.debian.org/20120502031200.GB18417@flying-gecko.net

Patrick Ouellette <pouelle@debian.org> writes:

> Of course the #! line is not the issue. The issue is two upstream
> maintainers separated by years and miles selected the same generic name
> for their binary file.

I agree with this.

> Compounding the issue, some Debian Maintainer seeking to better the
> project by packaging additional software for the project failed to
> perform "due diligence" in researching if any of the binary names from
> the proposed new package were already in use. Having packaged the
> software and uploaded it, someone noticed the issue and started us down
> the path we are on.

Maybe we should short-circuit this part of the conversation, since it
doesn't sound like you're horribly interested in agreeing to change the
name of node in the existing package.

I think it would make sense to take this to the Technical Committee at
this point and just make a decision, unless anyone thinks something
substantially new is likely to turn up. (We should probably give it a few
more days to see if anything does, but it's feeling increasingly unlikely
to me, as is the idea that we're all going to reach a consensus.)

--
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: 87y5pbi7xe.fsf@windlord.stanford.edu">http://lists.debian.org/87y5pbi7xe.fsf@windlord.stanford.edu

Hi again,

Steve Langasek wrote:

> [Dropped Cc; what does any of this have to do with the DPL?]

I was alerting him to a conversation that was going nowhere fast,
in the hope that he might use his power to

participate in discussions amongst the Developers in a helpful
way

It has also been my experience in the past that he is way better than
I am at figuring out a productive way forward when an endeavor is
stuck.

[...]
> I mean that it is not reasonable to expect a maintainer to recognize a
> "consensus" among other people who are not the maintainer, where his or her
> package is concerned, except when that's a consensus of a
> constitutionally-empowered body such as the TC.

That implies two bugs in debian-policy. You are probably right.

[...]
> The Technical Committee may:
>
> [...]
>
> 2. Decide any technical matter where Developers' jurisdictions overlap.

If I understand correctly, the general conclusion in this thread has
been that that is the right way to decide this.

I don't see anything fundamentally opposed to one another about the
goals of Pat, Jonas, and Jérémy, who seem to be the developers who
would be involved. The implied impossibility of a reasonable
conversation between them without some authority figure arbitrating is
a bit disappointing. Oh well.

[...]
> Ok - sorry, that's not what came across in your message, it's possible I
> overlooked some context up-thread that would have made this clear. Yes, a
> bug that's been filed against the package and gone unanswered by the
> maintainer is fair game for NMUing. OTOH, a bug that the maintainer
> disagrees is a bug would not be fair game.

Thanks again for the clarifications and sorry for the lack of clarity.
(Also sorry for the somewhat inflamatory way I've proceeded in this
discussion --- stating my biases up front and tying this in with my
concerns about lack of an active maintainer to vet changes to the node
package was probably not the best approach. Someone with a more
delicate touch could probably have gotten more done.)

Sincerely,
Jonathan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120502063443.GA2691@burratino">http://lists.debian.org/20120502063443.GA2691@burratino

* Russ Allbery <rra@debian.org> [120501 19:28]:
> 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.

On the other hand, if renaming both of them is the only possible outcome
if both parties cannot agree, it makes it more likely both sides will
actually be willing to discuss the matter, instead of just issuing demands,
hoping the other side will either give up or will be overruled by the
TC at the end.

Bernhard R. Link


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120502124909.GB18119@server.brlink.eu">http://lists.debian.org/20120502124909.GB18119@server.brlink.eu

On 02/05/2012 14:49, Bernhard R. Link wrote:
> * Russ Allbery <rra@debian.org> [120501 19:28]:
>> 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.
>
> On the other hand, if renaming both of them is the only possible outcome
> if both parties cannot agree, it makes it more likely both sides will
> actually be willing to discuss the matter, instead of just issuing demands,
> hoping the other side will either give up or will be overruled by the
> TC at the end.

Ok then, since i'm the nodejs maintainer, i'm willing to discuss this matter,
even privately if that is more effective, with someone representing the node
package, so we can close this issue in some way.

Jérémy Lal


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

On 2012-05-02 14:49:09 +0200 (+0200), Bernhard R. Link wrote:
> On the other hand, if renaming both of them is the only possible
> outcome if both parties cannot agree, it makes it more likely both
> sides will actually be willing to discuss the matter, instead of
> just issuing demands, hoping the other side will either give up or
> will be overruled by the TC at the end.

It seems to me to be more akin to, or some variant on, an
all-or-nothing Prisoner's Dilemma. Neither side is necessarily
encouraged to give in since the only "favorable" outcome for an
individual application--keeping its well-known name--comes from
holding out longest in the confrontation. In this scenario, altruism
on the part of one participant is the only alternative to preventing
an unfavorable outcome for both... and as such both sides (following
classic Game Theory principles) will default to the unfavorable
outcome. In other words, it does nothing to promote compromise
between uncooperative parties.

With the TC as an assumed impartial arbitrating body, this changes
the game to (theoretically) favor the side with the most effective
technical argument when neither can come to an agreement on their
own.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fungi@yuggoth.org); FINGER(fungi@yuggoth.org);
MUD(kinrui@katarsis.mudpy.org:6669); IRC(fungi@irc.yuggoth.org#ccl); }


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120502135222.GU723@yuggoth.org">http://lists.debian.org/20120502135222.GU723@yuggoth.org

+++ Patrick Ouellette [2012-05-01 23:12 -0400]:
> Of course the #! line is not the issue. The issue is two upstream maintainers
> separated by years and miles selected the same generic name for their binary
> file. Compounding the issue, some Debian Maintainer seeking to better the
> project by packaging additional software for the project failed to perform
> "due diligence" in researching if any of the binary names from the proposed
> new package were already in use.

Just a quick question - is there an easy way to do this? I worry
sometimes that I might be creating a binary name that is already used
somewhere, and thus a potential clash, but it is not obvious to me how
to check. Strictly this applies to every file in a package, although
clashes are most likely in /usr/bin


Wookey


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120502165354.GC13669@stoneboat.aleph1.co.uk">htt p://lists.debian.org/20120502165354.GC13669@stoneboat.aleph1.co.uk