Re: where is perl 5.6?
On Sun, Oct 01, 2000 at 10:27:43AM -0700, Darren/Torin/Who Ever... wrote:
>In my defense, in the last week, I've added interpreter threads, moved
>the perl-\d+-doc package to binary-indep and a few other things. Note
>that I've done -Dthreads -Dithreads since that's the future of threading
>in Perl rather than -D5005threads. If you need that, there is
>perl-5.005-threads.
More on threads below.
>I need to do a couple things to release 5.6.0-0.2:
> * get the update-alternatives priorities worked out so that perl 5.6
> comes out as the correct (highest) alternative
> * an alternate is to come up with some other way to have multiple
> Perls installed
> * Production environments regularly need multiple Perls installed so
> we can't go One Perl
My rationale for returning to a single perl is that from a packaging
perspective, I don't believe that having multiple versions of perl
works.
For unstable, there is still a transition period where all binary
modules must be re-built when a new perl version is added.
For stable, the `officially blessed' version of perl *must* be the
current /usr/bin/perl, or binary modules (which by this time should all
be compiled for that version) won't work. This will break any package
with a dependency on such modules.
In addition to the issue of binary modules, pure-perl modules/scripts
using features of the newer perl will break if an earlier version is
installed as the default.
The only alternative to a single perl that I can see is for programs to
explicitly use #!/usr/bin/perl-<ver>, packages to have dependencies on
perl-<ver> and to add a version number to binary modules.
Hardly an attractive alternative.
There are of course some compromises which must be made to retain the
limited backward binary compatibility of my proposal. Namely threads
and multiplicity.
I note that while there are currently a small number of packages which
depend on perl-5.005-thread/perl5-thread, none of which do so
exclusively (ie. perl-5.005/perl5 is also an acceptable candidate).
Multiplicity is only an issue for some programs with embedded
interpreters. Whether this includes any existing Debian packages I do
not know.
As far as the mooted production systems which require a particular perl
version are concerned, is there concrete evidence of this being a common
requirement? Any serious production environment would surely perform
testing of their *entire* system before dist-upgrading production
machines. If unresolvable issues with a newer perl version did actually
arise, nothing precludes them from building the older version in an
alternate location.
> * Build libperl-5.6 - should be easy, I've got the patches for it from
> Branden
I'm surprised that the X maintainer has the time to contribute patches
to perl :-)
Seriously though, no patch required. Just a multiple build, with
selected components taken from the shared and static builds.
> * Use the suggested method of removing unneeded libraries from the
> main Perl executable as suggested on p5p in
> <000e01c01bc2$88b2d2c0$0e14140a@bfs.phone.com> and
> <000001c020ef$d10c7120$1614140a@bfs.phone.com>.
> Something like this is in bleedperl now and will be in Perl 5.7.
Perl 5.7.0 (devel) was released a month ago. Or did you mean 5.7.n?
It is possible to remove these libraries more simply than the recent
changes discussed on p5p simply by post-editing config.sh.
AFAIK the only issue with doing it this way is that running Configure on
such a modified config.sh causes problems. We don't ship config.sh. No
problem.
Regards,
--
Brendan O'Dea bod@compusol.com.au
Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
Reply to: