On Wed, 9 May 2001, Alan Burlison wrote:
> Thanks, I'm conscious that binary compatibility is an important goal for
> perl. For Solaris however it is a 100% imperative, and somewhere something
> has to give... For 5.6.1 I'm building with -Duse64bitint, which breaks
> binary compatibility, which is proving to be an issue.
Since perl5 doesn't really have an XS api, I think 100% binary
compatibility has never been assured even across minor subversions.
But you're right: -Duse64bitint is definitely a breaker.
> I need to do some digging in perl.c then, as we tweak the directory
> structure in a somewhat non-standard fashion, so it may not still work in
> our case. Here is what we have:
> site-perl/
> [version]/ User-installed modules.
Offhand I think that's ok, provided you keep the new site libraries below
$Config{sitelib_stem}, as it appears you are likely to do. But please do
check me on that.
One gotcha other distributors have hit is that the automatic version
searching doesn't (by default) look back in $privlib (and $archlib)
because all the core modules in the old versions are replaced by the new
core modules in the new versions.
However, what if Sun installed additional, non-core modules for end-users
to use (e.g. Sun::Solaris)? The new version will not automatically load
them up if they are stored in $privlib or $archlib.
This can be a real problem if users do partial upgrades, particularly if
parts of the upgrade procedure use those perl modules! (This has often
been a problem for some Linux distributors, but may very well not be a
signficant issue for Sun.)
Hence, you have two choices:
1. In your upgrade, always include all the add-on modules for each
version.
2. Use the vendorlib hierarchy of directories for vendor-specific
modules. These use the same version-searching algorithm that the site-lib
directories do.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
