On Monday, December 9, 2002, at 03:20 PM, Michael Maibaum wrote:

Shouldn't we blame apple for making it harder than it should be?
I don't think so, because I don't see any way in which they've done that. Indeed, I think that they've simplified things a bit, by eliminating an extra set of directories that were of dubious benefit anyway.

How is apple going to upgrade their perl with this layout? by adding a Perl5.8 sub directory of /Library? (ie adding versioning like I would like?)
There are actually two separate issues: Installing multiple Perls, and surviving an update to the system Perl.

The first issue is clear, and the means to resolve it are fairly simple. Anyone who needs a working Perl environment that is guaranteed to remain untouched through any Apple updates needs to install their copy under a safe prefix. I think we agree on that - you said earlier that you've installed your copy of 5.8.0 under /opt. So, no matter what Apple does with their Perl, scripts that use #!/opt/bin/perl will continue to function properly.

The second issue is a bit more complex - what happens when, after having installed a series of CPAN modules into Apple's Perl (hence, in /Library/Perl), Apple then decides to upgrade their Perl to 5.8.0? What happens is, modules with an XS component will break, and will need to be reinstalled.

You suggest that, had Apple used a version-specific module directory, this sort of breakage would have been prevented. That is true only in a limited sense, in that the upgraded Perl would no longer attempt to load incompatible module versions. However, addressing that side of the issue would not magically cause the appearance of compatible modules in the new version's site_perl directory. In other words, it would not eliminate the problem; it would simply change the nature of the problem, from one concerning incompatible modules to one concerning missing modules. The means of fixing the problem would remain the same - modules with an XS component would need to be reinstalled.

What's more, unless "100% pure Perl" modules were stored in a version-agnostic location, they would then need to be reinstalled as well, whereas under the current layout, they can continue to be used as-is.

In effect, what you're proposing would complicate the directory structure, with little benefit to be had in return. Any CPAN modules that would have to be reinstalled after an upgrade with the current layout, would also need to be reinstalled if the traditional version-specific layout were used.

The sole benefit that the traditional layout has over the layout Apple uses is the ability for multiple versions to coexist peacefully - and that benefit is of limited scope, as the traditional layout allows only for multiple trees of modules. Man pages and tools in the bin directory will be from the latest installed version. A much more elegant and complete means of installing multiple versions and ensuring their separation from one another is to specify a different prefix for each, and allow each to install its own set if bin/, lib/, and man/ subdirectories under that.

It appears to me that Apple has pretty closely examined this and many other aspects of the traditional UNIX system, and attempted to determine, on the basis of merit alone, whether tradition in each case should be followed, or discarded in favor of something better. This is hardly surprising; Apple is notorious for questioning assumptions and for forging their own path whenever they have felt it necessary.

sherm--

If you listen to a UNIX shell, can you hear the C?



Reply via email to