On Wednesday, December 11, 2002, at 08:56 AM, Chris Nandor wrote:
works well for me, and I find no significant maintenance issues as outlinedI wasn't my intent to point out problems in the traditional layout; I was simply pointing out that the most common complaint about Apple's layout - the need to reinstall CPAN XS modules after an upgrade - isn't addressed by the traditional layout either. Using Apple's layout, you get incompatible CPAN modules in the common directory; using the traditional layout, you wind up with CPAN modules missing from a version-specific directory. The cure for both problems is identical - reinstall the affected modules.
by Sherm.
The biggest benefit the traditional layout has over Apple's is the ability to install multiple versions that share the same installation prefix; I would argue that a) If multiple Perl versions are needed, a simpler and cleaner way to accomplish that is to use a different prefix for each, and that b) The vast majority of Apple's user base won't need multiple Perls anyway, leading Apple to choose to simplify the directory structure for the most common case.
It's trivially simple for an experienced admin to install multiple Perls under different prefixes - something that worked well even with older 5.x versions that didn't use the current layout, and even with 4.x and earlier versions. With that in mind, it appears to me that the traditional layout is intended to solve a social engineering problem, not a technical one. It would seem that the *real* question that's addressed by the default layout is how to minimize the damage that's done when a less experienced admin simply types "./Configure; make; make install". The result, while sub-optimal, will at least allow both the old and new installations to continue functioning. It follows the Perl tradition of making the easy, default install even easier, without making the advanced multiple-prefix install any more difficult.
sherm--
If you listen to a UNIX shell, can you hear the C?
