There are no code issues per se... but their are issues with saved regression test results.... Yea, I have typically built my own perl tree in the past.... and that is the only way I would go with Solaris or HPUX, and that is what I do at work. The gentoo system looked so strong I thought I would try to use the built in perl. May still, since I think I have solved most of the ordering of key problems in regression test outputs, but using some functionality we had for explicitly controlling key order, which is required for compatibility with some rather non-compliant xml interfaces we use at work.
Thanks. Lincoln On Mon, 2003-02-10 at 07:52, D. Wollmann wrote: > On Sunday 09 February 2003 15:28, Lincoln A. Baxter wrote: > > I have discovered that I need to run perl 5.6.1 in stead of 5.8.0 (there > > are subtle changes to the way hashes are handled that I cann't work > > around right now) so I installed the earlier version of perl with the > > ebuild command: > > > > ebuild EBUILD_FILE merge > > > > Now it seems that the system is not being consistent about where > > the site_perl directory lives. There is a directory in /usr/lib AND > > there is a directory in /usr/lib/perl5. portage and perl do not seem to > > agree. > [snip] > > "Subtle changes to the way hashes are handled" shouldn't break code, unless > you're doing something "unusual". Can you show a snippet of code that > demonstrates the problem? > > As for running a release of Perl other than the current release on a > package-managed system, the best approach I've found is to leave the system's > Perl package in place and create custom Perl builds in a private tree. This > way you don't risk breaking things that other parts of your system may depend > on. I'm not certain of gentoo's policy on Perl dependencies, so this may not > be a big concern in this case, but as a matter of habit it's safer and easier > to deal with. > > On my systems I have private builds of 5.005_03, 5.6, and a private threaded > 5.8 built with Intel's C Compiler, and have links in ~/bin so I can run any > program with any version without a fuss. -- Lincoln A. Baxter <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
