Le Thu, May 13, 1999 at 09:16:11AM -0400, Zephaniah E. Hull écrivait: > Specificly the path issues and the mention of the bug reports..
About the bugs, here they are : http://www.debian.org/Bugs/db/35/35236.html http://www.debian.org/Bugs/db/35/35446.html And there are path problems IF perl5.005 is used and IF perl5.005 is compiled without /usr/lib/perl5 in @INC. But with the solutions proposed in those bug reports, there won't be any problems at all (with perl5.004 or perl5.005 and any further version). > This gives the impression that you are quite unaware that perl5.005 > should have little to no effect on ANY packages which are currently in > use, as perl5.004 will continue to be used by things.. This is true if perl5.004 will still be used, but as you know, perl5.005 has some binary incompatiblity for binary modules. And actual binary modules will be replaced by newly compiled ones and will depend on perl5.005. So if you have one binary module on your system and if people upgrade it, perl5.005 will be automatically installed. And /usr/bin/perl will be changed. And then the problems may arise. And last I talked with Darren, he said that he will need to add /usr/lib/perl5 to @INC at least for potato (woody's perl may get rid of it) in order not to have to conflict with specific version of netstd and/or netbase. Because actually there are postinst script that do NOT run if you use perl5.005 without /usr/lib/perl5 in @INC. Look at netstd's and netbase's postints. BTW, I think there's a similar problem for the PDL package. > (There are a few minor issues which still need to be worked out, for > instance perl-base and deciding which perl will become essential, > however the basic upgrade path is that NOTHING breaks as perl5.004 > continues to be used by things) That's ok, as long as you do not upgrade binary perl modules. Cheers, -- Hertzog Raphaël >> 0C4CABF1 >> http://prope.insa-lyon.fr/~rhertzog/
