[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#614907: Draft resolution for node+nodejs

So the deadline I set myself for this is now long past; sorry about that.
Responding to comments - call for votes will come in a separate message.

On Fri, Jun 29, 2012 at 12:20:24PM +0100, Colin Watson wrote:
> On Thu, Jun 28, 2012 at 12:52:39PM -0700, Steve Langasek wrote:
> > Sorry this is so long in coming.  Here's the draft resolution for this
> > issue, agreed at the last IRC meeting.

> > I thought about including a statement censuring nodejs upstream for their
> > unhelpful behavior around this issue, but we didn't actually discuss that at
> > the IRC meeting so I don't know if there's a consensus and don't want to
> > hold this up any further.

> Situations like the one in this bug really have no terribly satisfactory
> answer.  Whatever we do (including nothing!), some users are likely to
> end up being inconvenienced.  I don't know how much issuing a censure
> would achieve - we can say it all we like, and I might well agree, but
> if they were going to pay attention then my suspicion is that we
> wouldn't have had this problem in the first place! - but I think it
> would be useful to take this situation as an opportunity to remind the
> wider free software world about the importance of playing nicely with
> the command namespace in the hope of reducing future problems.  If this
> were picked up by technical news outlets then it might actually be a
> vaguely useful thing to do.

> I understand why you didn't want to hold up your resolution text on
> anything along these lines.  Still, we can quite reasonably vote on such
> a statement independently.


> I'd like to suggest a statement under §6.1.5 along the following lines:

>   The Technical Committee notes that the namespace of executable
>   commands on $PATH is a resource shared among everyone writing software
>   for POSIX-compatible systems, and that the combinations of packages
>   that users may choose to install on a given system can easily surprise
>   the authors of those packages.

>   The Committee advises anyone writing widely-deployed software to
>   consider its command name carefully at an early stage.  It is a good
>   idea to search the web for your proposed name and try to ensure that
>   it is unique.  It is likely to be a bad idea to use excessively short
>   names or common words.  The conflict between LinuxNode and Node.js
>   demonstrates that taking a little time early on can avoid a great deal
>   of tedium later.

>   The Committee furthermore reminds Debian Developers that they are in
>   an excellent position to assist upstream authors with identifying and
>   resolving conflicts at an early stage, and that they should do so as
>   soon as possible rather than deferring the problem until later and
>   thus entrenching the naming conflict.

I'd happily vote in favor of this as a separate statement.

> > === Resolution ===
> > The Technical Committee reaffirms the importance of preventing namespace
> > collisions for programs in the distribution, while recognizing that
> > compatibility with upstreams and with previous Debian releases is also
> > important and that sometimes an imperfect balance must be struck between
> > these three goals.

> > The Committee therefore resolves that:

> > 1. The nodejs package shall be changed to provide /usr/bin/nodejs, not
> >    /usr/bin/node.  The package should declare a Breaks: relationship with
> >    any packages in Debian that reference /usr/bin/node.

> For consistent tense, I think s/should/shall/.

This was a deliberate word choice in that I don't think this is as critical
as the rest; a missing breaks would be a comparatively minor bug.  Changed,
all the same.

> > 2. The nodejs source package shall also provide a nodejs-legacy binary
> >    package at Priority: extra that contains /usr/bin/node as a symlink to
> >    /usr/bin/nodejs.  No package in the archive may depend on or recommend
> >    the nodejs-legacy package, which is provided solely for upstream
> >    compatibility.  This package declares shall also declare a Conflicts:
> >    relationship with the node package.

> Typo: probably just "This package shall also declare".

Yes, definitely.

> Also, my apologies if this has been discussed already as I'm coming to
> this discussion very late, but isn't this a fairly rough transition?  If
> I were designing this, there would be a period whereby users of the
> existing nodejs binary package are upgraded to a system with both nodejs
> and nodejs-legacy, to minimise breakage.

> If this has been discussed already and refuted for some reason, feel
> free to point me at the messages I missed.

So the nodejs package is considered RC buggy at the moment because of this
namespace collision, and therefore the transition is entirely confined to
unstable (and possibly third-party packages).  The consensus in the IRC
meeting was that we don't want to bless use of the /usr/bin/node name by
nodejs beyond what's absolutely necessary for compatibility for third-party

> > 3. The node source package shall rename its binary to /usr/sbin/ax25-node,
> >    and its binary package to ax25-node.
> > 4. The node source package shall continue to build a transitional 'node'
> >    binary package for compatibility with deployed Debian installations,
> >    which provides /usr/sbin/node as a symlink to /usr/sbin/ax25-node.  This
> >    package shall declare a reciprocal Conflicts: relationship with the
> >    nodejs-legacy package.  Other packages may reference the 'node' package
> >    as a dependency or recommendation, but are encouraged to transition to
> >    'ax25-node'.

> By contrast, this is a much smoother transition.

Yes, the difference is quite deliberate.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: