Sorry to join this discussion late... On Friday, January 10, 2003, at 09:49 PM, Benjamin Reed wrote:
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.No, that's not right at all. As I discussed with rangerrick on the submission tracker, Perl already HAS a standard for dealing with binary incompatible modules. Apple stupidly overrode that mechanism and we've been dealing with it ever since.
By default, Perl creates a 5.6.0 and site_perl/5.6.0 or 5.8.0 and site_perl/5.8.0 directory beneath the lib/perl5 dir. The .info file I created last summer(?) did exactly that. It had several other flaws, but incompatibility with the 5.6.0 distro was not one of them. Just try that .info file and you'll see.
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.With the exception of the /sw/lib/perl dir (no! it should be /sw/lib/perl5!), this is good, and is very similar to what I advocated to rangerrick. We should think carefully about where we want the user-installed packages to go. In /sw? in /usr/local? Somewhere else?
So what we end up with is: - old perl modules: /sw/lib/perl5
Yes.
- official stuff that comes with perl: /sw/lib/perl/5.8(/darwin)?
No. /usr/lib/perl5/5.8.0{,/darwin} as per the perl default
- stuff that's installed by users in the fink tree (bad!) /sw/lib/perl/5.8/site_perl(/darwin)?
/usr/lib/perl5/site_perl/5.8.0
- stuff that's installed by fink packages: /sw/lib/perl/5.8/vendor_perl(/darwin)?
OK, how about /sw/lib/perl5/fink_perl/5.8.0
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.
Well *at least* it should be 5.8.0, not 5.8.
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.Hmm, no. I think that perl 5.6.0 and 5.8.0 should happily coexist. That's the way it works on every unix platform except OSX. Just because Apple screwed this up doesn't mean we should, too.
Does that make sense?
I, for example, run 5.6.0 with mod_perl (since Apple's mod_perl distro is hard-coded to their 5.6.0 release) and 5.8.0 for everything else. There is absolutely no need to make the users change their 5.6.0 setup to get 5.8.0 functionality.
Chris
-------------------------------------------------------
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
