Darren/Torin/Who Ever... [EMAIL PROTECTED] writes:
Any debian packages and all architecture dependent packages will have to
be recompiled.
Since new Perls seem to break binary compatibility, do we need a
better dependency mechanism?
The best option I can see is for perl_5.005 (or perl_base,
Raphael Hertzog [EMAIL PROTECTED] writes:
Le Sat, Oct 03, 1998 at 06:32:22PM -0500, Manoj Srivastava écrivait:
I agree.
I do not. Perl 5.005 and the new perl-thread seems to interest a lot of
people. But if we don't switch to perl5.005 right now, they would presumably
download the
Le Mon, Oct 05, 1998 at 01:57:46AM -0400, Adam P. Harris écrivait:
C'mon, let's be realistic. Introducing a new perl right now would
basically blow a 1998 stable slink out of the picture (as would PAM,
of course), IMHO. It's not just a question of re-uploading 35
packages, but also of
On Mon, 5 October 1998 13:24:56 +0200, Raphael Hertzog wrote:
Yes, if we do nothing for slink then we will have to make perl5.005 (and
all perl package after 5.005) conflict with a list of 35 package with
precise version.
Yep. Seems more of a hassle to me.
Perl 5.005 is stable.
If we use
[snip]
Now. Who comes up with a Perl 5.005_02 for experimental?
I'd like to run it against the walls to see if it does
anything not-so-nice or something.
Alexander
--
Heute nacht war mir fuenf Minuten langweilig... -- Gabriel Krabbe
Alexander Koch - - aka Efraim - PGP - 0xE7694969 - Hannover
Le Mon, Oct 05, 1998 at 06:41:47PM +0200, Alexander Koch écrivait:
Now. Who comes up with a Perl 5.005_02 for experimental?
I'd like to run it against the walls to see if it does
anything not-so-nice or something.
[I don't answer, I try to summarize]
AFAIK, Darren Stalder (the perl
Hi,
Raphael == Raphael Hertzog [EMAIL PROTECTED] writes:
Raphael Le Sat, Oct 03, 1998 at 07:21:06PM +0200, Richard Braakman écrivait:
Let's wait till *after* the freeze and do that in the new unstable.
I agree.
Frankly, I think it's a bad idea to just break all those packages.
Hi,
Raphael == Raphael Hertzog [EMAIL PROTECTED] writes:
Raphael Why not propose perl and perl-thread ? Each one would
Raphael conflict with the other one, but that's not a problem.
That *is* a problem. I would like to have both on my machine:
the normal perl for production, and the
Manoj Srivastava wrote:
That *is* a problem. I would like to have both on my machine:
the normal perl for production, and the threaded one to prototype
with.
According to the mail I got from the maintainer, that is what he plans to
do. /usr/bin/perl and /usr/bin/perl-thread, no
Le Sat, Oct 03, 1998 at 09:14:00PM -0500, Manoj Srivastava écrivait:
That *is* a problem. I would like to have both on my machine:
the normal perl for production, and the threaded one to prototype
with.
OK, I was wrong. I said it in the eventuality where perl and perl-thread
would
Le Sat, Oct 03, 1998 at 06:32:22PM -0500, Manoj Srivastava écrivait:
I agree.
I do not. Perl 5.005 and the new perl-thread seems to interest a lot of
people. But if we don't switch to perl5.005 right now, they would presumably
download the forthcoming perl5.005 package from the next (after
-BEGIN PGP SIGNED MESSAGE-
Raphael Hertzog, in an immanent manifestation of deity, wrote:
What will be done for slink ? I don't know but I'd like to have perl5.005
because it's better (ie. thread support is really useful). But then all
lib*-perl maintainer will have to upload updated
Darren Stalder wrote:
BTW, Joey, some of my projects could *really* use threaded Perl as
well. But it's considered experimental in 5.005 and just isn't up to
snuff in a production environment.
Do you have any plans to offer it as something like /usr/bin/perl-t? (or
would modules need to be
-BEGIN PGP SIGNED MESSAGE-
Joey Hess, in an immanent manifestation of deity, wrote:
Do you have any plans to offer it as something like /usr/bin/perl-t? (or
would modules need to be rebuilt too?)
It will be available as /usr/bin/perl5.00502-thread. I could manage the
/usr/bin/perl-t as
Darren/Torin/Who Ever... wrote:
It will be available as /usr/bin/perl5.00502-thread. I could manage the
/usr/bin/perl-t as alternatives.
Well /usr/bin/perl-thread is probably a better name.
Any debian packages and all architecture dependent packages will have to
be recompiled.
Do you
Darren/Torin/Who Ever... wrote:
Joey Hess, in an immanent manifestation of deity, wrote:
Do you have any plans to offer it as something like /usr/bin/perl-t? (or
would modules need to be rebuilt too?)
It will be available as /usr/bin/perl5.00502-thread. I could manage the
/usr/bin/perl-t
Martin Schulze wrote:
Darren/Torin/Who Ever... wrote:
Joey Hess, in an immanent manifestation of deity, wrote:
Do you have any plans to offer it as something like /usr/bin/perl-t? (or
would modules need to be rebuilt too?)
It will be available as /usr/bin/perl5.00502-thread. I could
Le Sat, Oct 03, 1998 at 07:21:06PM +0200, Richard Braakman écrivait:
Let's wait till *after* the freeze and do that in the new unstable.
Frankly, I think it's a bad idea to just break all those packages. Isn't
there some way to create a smooth upgrade path?
No. But it might no be a great
Le Thu, Oct 01, 1998 at 10:08:01PM -0400, Roderick Schertler écrivait:
One wouldn't want to switch /usr/bin/perl to have threading enabled at
this point, as there is still a significant speed penalty (somewhere in
the neighborhood of 30%, even if you haven't spawned any auxiliary
threads). I
19 matches
Mail list logo
