FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-09-2011, 02:16 PM
Patrick Ouellette
 
Default Is anyone maintaining (the ham radio tool) node?

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

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

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

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

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

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

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


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

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

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

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

Earlier when this particular situation was being discussed, someone mentioned
the generic name "node" was bad for a computer binary. 10-15 years ago it
was a different landscape. The node.js folks should probably have given
more thought to their binary's name given the nature of the computer software
landscape at the time they created their program. I can see the logic in
this argument, and so can support changing *both* binaries.

I recall this situation earlier for the axlisten binary. Back when I was
maintaining the ax25-* packages alone, someone complained that listen
conflicted with their audio player (I think) with the same binary name. I
argued for the ax25-* package and prevailed. A couple of years later after
I was no longer maintaining the ax25-* packages someone complained again
and the maintainer for the ax25-* packages decided to change the name to
axlisten.


Thanks for your questions and input!

Pat
--

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

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111109151610.GA23730@flying-gecko.net">http://lists.debian.org/20111109151610.GA23730@flying-gecko.net
 
Old 11-09-2011, 11:12 PM
Bob Proulx
 
Default Is anyone maintaining (the ham radio tool) node?

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
 
Old 11-14-2011, 07:09 PM
Vincent Bernat
 
Default Is anyone maintaining (the ham radio tool) node?

OoO En ce début d'après-midi nuageux du lundi 07 novembre 2011, vers
14:42, Ian Jackson <ijackson@chiark.greenend.org.uk> disait*:

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

As Patrick said earlier in the thread that not enough members seem to
care about this, I add my voice here: node from node.js is often used in
shebang while node from AX25 is not. Having a "nodejs" binary will
cause many difficulties to our users.

What if the problem was raised ten years ago about Python for
example. What an horrible mess it would be today if the python binary
was called "python-py" or "python-script".

See how communities may react to this. Ruby community does not like our
packaging just because we enforce stability over freshness. What would
think node.js community if we are using /usr/bin/nodejs instead of
/usr/bin/node. Debian would be listed as a black sheep in every FAQ or
tutorial and users will be invited to just install some non official
package or use the source.

Patrick seems OK for both binaries to be renamed. I don't see the
rationale of not accepting that node.js keeps the "node" name.
--
Vincent Bernat ☯ http://vincent.bernat.im

Modularise. Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)
 
Old 11-14-2011, 07:57 PM
Cyril Brulebois
 
Default Is anyone maintaining (the ham radio tool) node?

Vincent Bernat <bernat@debian.org> (14/11/2011):
> See how communities may react to this. Ruby community does not like our
> packaging just because we enforce stability over freshness. What would
> think node.js community if we are using /usr/bin/nodejs instead of
> /usr/bin/node. Debian would be listed as a black sheep in every FAQ or
> tutorial and users will be invited to just install some non official
> package or use the source.

Oh noes!!!!1111oneoneoneeleven

Mraw,
KiBi.
 
Old 11-14-2011, 08:40 PM
Jonathan Nieder
 
Default Is anyone maintaining (the ham radio tool) node?

Cyril Brulebois wrote:
> Vincent Bernat <bernat@debian.org> (14/11/2011):

>> See how communities may react to this. Ruby community does not like our
>> packaging just because we enforce stability over freshness. What would
>> think node.js community if we are using /usr/bin/nodejs instead of
>> /usr/bin/node. Debian would be listed as a black sheep in every FAQ or
>> tutorial and users will be invited to just install some non official
>> package or use the source.
>
> Oh noes!!!!1111oneoneoneeleven

Or to put it another way, one could kindly explain to such people that

(1) the node.js packaging in unstable or experimental is reasonably up to
date (if that is true --- I just don't know, but it presumably could
be easily could be made to be so if someone wants to do that)

(2) faced with a diverse userbase that was using the "node" command for
two different purposes, Debian is doing the only thing it can do to
make scripts reliable: rename both. As a nice side-effect, we get a
simple, Google-able name for the tool. People unhappy with the
divergence from upstream can do one of two things:

(a) install a /usr/local/bin/node -> ../../bin/nodejs symlink locally,
by running the following handy install-nodejs-symlink script

(b) work with upstream to provide the interpreter under both names,
so scripts can use "#!/usr/bin/env nodejs" to be self-documenting
and work reliably everywhere

(By the way, most of the description under (2) might apply to the ham
radio tool, too. In other words, none of this seems particularly unique
to interpreted languages.)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111114214013.GA3268@elie.hsd1.il.comcast.net">ht tp://lists.debian.org/20111114214013.GA3268@elie.hsd1.il.comcast.net
 
Old 11-15-2011, 03:31 PM
Jonas Smedegaard
 
Default Is anyone maintaining (the ham radio tool) node?

On 11-11-09 at 08:33am, Philipp Kern wrote:
> On 2011-11-08, Patrick Ouellette <pat@flying-gecko.net> wrote:
> > I hope to avoid any issues with breaking old boxes with the eventual
> > resolution of the issue.
>
> I don't know what's wrong with Jonathan Nieder's advise in [0] about
> helping users with the conversion automatically. That's how it's
> usually done.
> He even provided that patch.
>
> 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
 
Old 11-16-2011, 07:04 PM
Joey Hess
 
Default Is anyone maintaining (the ham radio tool) node?

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_dat e=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
 
Old 11-16-2011, 07:38 PM
Patrick Ouellette
 
Default Is anyone maintaining (the ham radio tool) node?

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 pat@flying-gecko.net
ne4po (at) arrl (dot) net Amateur Radio: NE4PO

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111116203827.GA29795@flying-gecko.net">http://lists.debian.org/20111116203827.GA29795@flying-gecko.net
 
Old 11-16-2011, 09:15 PM
Joey Hess
 
Default Is anyone maintaining (the ham radio tool) node?

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
 
Old 11-16-2011, 09:25 PM
Damien Gardner Jnr
 
Default Is anyone maintaining (the ham radio tool) node?

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19AA06CA-6B10-4538-BF61-6BF105677EBB@rendrag.net">http://lists.debian.org/19AA06CA-6B10-4538-BF61-6BF105677EBB@rendrag.net
 

Thread Tools




All times are GMT. The time now is 09:52 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org