Re: [Pkg-javascript-devel] 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 signature.asc Description: Digital signature ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Is anyone maintaining (the ham radio tool) node?
On Wed, Nov 09, 2011 at 08:33:38AM +, Philipp Kern wrote: > > On 2011-11-08, Patrick Ouellette 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 p...@flying-gecko.net ne4po (at) arrl (dot) net Amateur Radio: NE4PO What kind of change have you been in the world today? ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Hello Dear
Hello Dear My name is goodness,In search of one who understands love as trust and faith rather seeing it as a way of fun, but a mature one with good sense of humor,I got your contact today,i develop interest on you, I believe we can start from here,Am waiting to hear from you so that i will send you my pictures and further introductions. kiss from. Miss goodness___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] Hello Dear
Hello Dear My name is Lina Michel(female), i saw your mail today and i decided to contact you. I would like to be your good friend. I will like to know more about you,learn a lot from you .when i receive your yes answer,i will send you my picture for you to see me and tell you more about myself. yours new friend, Lina___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] Is anyone maintaining (the ham radio tool) node?
On 2011-11-08, Patrick Ouellette 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 ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
