[Fink-devel] perl 5.8 thoughts and testing

[Benjamin Reed]

So the subject of perl 5.8 came up again on #fink, and I started taking a look at what we had. Chris Dolan put together a great package for perl 5.8, but it has one problem -- it still puts everything in /sw/lib/perl5 just like our 5.6 packages. The problem is perl 5.6 modules are not binary-compatible with perl 5.8, and having it put things in the same place makes it very difficult to determine what needs to be upgraded and what doesn't.

The solution I came up with was to make the new perl install to /sw/lib/perl directory instead. On top of that, I've changed things around so that we are using another handy feature of recent perl versions -- a "vendor" tree, that allows us to make a separate directory for fink-installed packages (as compared to packages that joe blow installs on the command-line with CPAN). This will make diagnosing problems easier in the long-run, because packages that are installed by end-users on their own will be compartmentalized away from supported, official fink perl modules. We could even have fink warn if there's any files in site_lib at all.

So what we end up with is:

- old perl modules:
/sw/lib/perl5

- official stuff that comes with perl:
/sw/lib/perl/5.8(/darwin)?

- stuff that's installed by users in the fink tree (bad!)
/sw/lib/perl/5.8/site_perl(/darwin)?

- stuff that's installed by fink packages:
/sw/lib/perl/5.8/vendor_perl(/darwin)?

I've made a preliminary patch to fink that looks for /sw/lib/perl and /sw/bin/perl. If they exist, they use the perl -V:vendor* variables to determine where perl modules should go (in case future fink perls move things around a bit).

The lib/perl/5.8 lets us separate things out for future binary incompatibilities, as well.

As far as an upgrade path, the biggest issue is determining how to make sure that things get upgraded as soon as perl is upgraded.

The actual upgrade process should be easy, we would do something like:

find /sw/lib/perl5 -type f | xargs dpkg -S | awk -F: '{ print $1 }' | sort | uniq

...and take the output of that as the list of things that need rebuilding.

Oh, I guess add "| grep -v fink" to that. <grin>

One of the biggest issues to handle will be packages that have to do their own thing in info files. There are a number of perl modules that do "perl Makefile.PL blah blah" rather than use "Type: perl", which will obviously have the wrong path and will be unavailable to perl 5.8 (since 5.8 is now configured to *not* look in /sw/lib/perl5 to avoid conflicts).

So in short, it appears the technical part is going to be easier than it looked at first, but the upgrade path is going to be difficult to coordinate. Perhaps it would be best to do something like this:

The perl package has a pre-install script that checks /sw/lib/perl5 to see if there's anything left. If there is, it bombs, and points you at a "upgrade-perl-modules.sh" script that will do everything at once. Once it's been done, future perl package releases would work just fine.

Does that make sense?



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel