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 > <[EMAIL PROTECTED]> and > <[EMAIL PROTECTED]>. > 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 [email protected] Compusol Pty. Limited (NSW, Australia) +61 2 9810 3633
