On Tue, May 08, 2012 at 12:41:40PM +1000, Ben Finney wrote:
>
> David Weinehall writes:
>
> > Wasn't the main reason (apart from the seniority argument) for
> > preserving the node name for ax25 to prevent remote unmonitored highly
> > important systems from failing?
>
> If such systems are hig
On 12-05-07 at 11:28pm, Steve Langasek wrote:
> On Sun, May 06, 2012 at 09:49:11PM +0200, Jonas Smedegaard wrote:
> > On 12-05-06 at 10:22am, Steve Langasek wrote:
> > > On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> > > > We have until now maintained Nodejs only in unstable be
OoO Pendant le journal télévisé du lundi 07 mai 2012, vers 20:41, Philip
Hands disait :
>> Package: node
>> Depends: ax25-node
>> Conflicts: nodejs
>> -- /usr/sbin/node -> /usr/sbin/ax25-node
>>
>> Package: ax25-node
>> -- /usr/sbin/ax25-node
>>
>> Package: nodejs
>> Conflicts: node
>> -- /usr/
On Sun, May 06, 2012 at 09:49:11PM +0200, Jonas Smedegaard wrote:
> On 12-05-06 at 10:22am, Steve Langasek wrote:
> > On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> > > We have until now maintained Nodejs only in unstable because
> > > requests to rename axnode was met with ei
David Weinehall writes:
> Wasn't the main reason (apart from the seniority argument) for
> preserving the node name for ax25 to prevent remote unmonitored highly
> important systems from failing?
If such systems are highly important, should we accomodate them
remaining unmonitored?
Surely if th
On Mon, May 07, 2012 at 07:41:33PM +0100, Philip Hands wrote:
[snip]
> It also prevents a HAM from deciding to dabble in Node.js while
> preserving the 'node' name for their ax25 use.
Wasn't the main reason (apart from the seniority argument) for
preserving the node name for ax25 to prevent remote
On 07/05/12 19:41, Philip Hands wrote:
> The -legacy was meant
> to be an attention grabber, and perhaps to reflect a hope that at some
> point in the future one or both upstreams might switch to a better name.
I think "legacy" is rather misleading, since its upstream
(unfortunately) doesn't think
On Sun, 6 May 2012 10:29:18 -0700, Steve Langasek wrote:
> On Sat, May 05, 2012 at 08:29:40AM +0100, Philip Hands wrote:
> > How about doing the following:
>
> > node package replaced by a node-legacy package that contains no more
> > than a README and a symlink node --> ax25-node, and depend
On 12-05-06 at 11:00pm, Thomas Preud'homme wrote:
> Le dimanche 6 mai 2012 21:49:11, Jonas Smedegaard a écrit :
> > Greetings, dear Debian developer,
> >
> > [replying via bugreport as I am not subscribed to tech-ctte@d.o]
> >
> > On 12-05-06 at 10:22am, Steve Langasek wrote:
> > > On Sat, May 05
Le dimanche 6 mai 2012 21:49:11, Jonas Smedegaard a écrit :
> Greetings, dear Debian developer,
>
> [replying via bugreport as I am not subscribed to tech-ctte@d.o]
>
> On 12-05-06 at 10:22am, Steve Langasek wrote:
> > On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> > > We hav
Greetings, dear Debian developer,
[replying via bugreport as I am not subscribed to tech-ctte@d.o]
On 12-05-06 at 10:22am, Steve Langasek wrote:
> On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> > We have until now maintained Nodejs only in unstable because
> > requests to re
On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> We have until now maintained Nodejs only in unstable because requests to
> rename axnode was met with either silence or refusal with the reasoning
> that axnode was more widely used in Debian than Nodejs.
> Obviously Nodejs is n
On Sat, May 05, 2012 at 08:29:40AM +0100, Philip Hands wrote:
> How about doing the following:
> node package replaced by a node-legacy package that contains no more
> than a README and a symlink node --> ax25-node, and depends on
> ax25-node
As mentioned by Carsten Hey on debian-ctte, we s
Thibaut Paumard writes:
> As I understand it, Policy is broken here: if the two binaries where
> installed in /usr/bin, it would be fine (Policy-wise) to Conflict.
Our current Policy specifically prohibits that. See Policy 10.1:
Two different packages must not install programs with differe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 05/05/12 09:29, Philip Hands a écrit :
> On Fri, 4 May 2012 19:00:10 +0200, Pau Garcia i Quiles
> wrote: ...
>> Agreed. That's why my proposal was that *all* of those (Debian,
>> Fedora, Suse, MacPorts and brew) did the rename, not just us
>>
On Fri, 4 May 2012 19:00:10 +0200, Pau Garcia i Quiles
wrote:
...
> Agreed. That's why my proposal was that *all* of those (Debian,
> Fedora, Suse, MacPorts and brew) did the rename, not just us (Debian).
> It's certainly not nice to push upstream to do something they don't
> want to do, but when
On 12-05-02 at 05:10pm, Patrick Ouellette wrote:
> On Tue, May 01, 2012 at 08:22:05PM -0700, Russ Allbery wrote:
> >
> > 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 exist
On Fri, May 4, 2012 at 6:53 PM, Steve Langasek wrote:
> Hi Pau,
>
> On Fri, May 04, 2012 at 04:24:21PM +0200, Pau Garcia i Quiles wrote:
>> Regarding the often-mentioned "many users run 'node script' from the
>> command-line"... so what? If we can get enough distributions (Debian,
>> Suse, Fedora,
Le Thu, May 03, 2012 at 12:39:04PM -0400, Joey Hess a écrit :
>
> Consider a package that contains a node.js script, which is not the
> primary purpose of the package. So it Recommends, rather than depends
> on nodejs. (Let's assume it uses #!/usr/bin/env node, and for the sake
> of example is som
Charles Plessy wrote:
> If we would tolerate conflicts, we would not support the parallel use of some
> of our packages, but there would be the benefit that the package dependancy
> graph could be parsed to report clusters of mutually-incompatible packages.
> Often, these incompatibilities will not
Hi all,
I think that we are asking the impossible, to be universal, cover a large
number of fields, and fit all of this in a single name space witout conflicts.
With our current approach, to rename at least one of the program names, we make
Debian systems incompatible with outside documentation a
On Wed, May 02, 2012 at 06:43:04PM +0100, Neil Williams wrote:
>
> There's also http://packages.debian.org/#search_contents which can
> search for files listed within packages.
>
That's where I check.
Pat
--
,-.
> Pat
On Tue, May 01, 2012 at 08:22:05PM -0700, Russ Allbery wrote:
>
> 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. :)
>
Actually, despite my vigorous defense of
Patrick Ouellette writes:
> I'm more than a bit disappointed that this will be the second time a ham
> radio tool in Debian is forced to use a name the wider Linux ham
> community does not use. No one seems to be considering the issues or
> complications caused to the ham users. I've heard the
On Wed, May 02, 2012 at 05:53:54PM +0100, Wookey wrote:
> 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 appli
On Wed, 2012-05-02 at 17:53 +0100, Wookey wrote:
> +++ 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 issu
]] Wookey
> Just a quick question - is there an easy way to do this?
Given most names don't explain particularly well what the command does,
just use something inspired by pwgen.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to
On Wed, 2 May 2012 17:53:54 +0100
Wookey wrote:
> +++ Patrick Ouellette [2012-05-01 23:12 -0400]:
> > 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
Wookey writes:
> 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
+++ 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 p
Patrick Ouellette 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
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
> Subject: Re: [Pkg-javascript-devel] Node.js and it's future in debian
> To: debian-devel@lists.debian.org
>
> Patrick Ouellette writes:
> >
Patrick Ouellette 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 th
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
That is truely messed up!
Pat
--
,
+1 to let Node.js be just "node"
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f9ea18a.8030...@gmail.com
On Apr 29, Harald Jenny 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
signature.asc
On Sun, Apr 29, 2012 at 04:23:25PM +0200, Marco d'Itri wrote:
> On Apr 29, Harald Jenny 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 o
On Apr 29, Harald Jenny 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
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 nam
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
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 th
On 12-04-28 at 03:31am, Carl Fürstenberg wrote:
> 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.
>
> To summarize the problem:
> * the nodejs upstream binar
42 matches
Mail list logo
