Re: Apple Perl directory layout

[Wilfredo Sánchez]

  The versioned structure was not.  That's why I didn't use it.  
Instead, I relied on dyld's ability to keep track of compatibility 
version in the dylib.

	-wsv


On Tuesday, December 17, 2002, at 09:29  AM, Dan Sugalski wrote:

It's important to note that the directory structure was *not* meant to 
deal with this sort of problem. What it was meant for was to provide 
the ability to have multiple versions of perl installed simultaneously 
as a means of preventing breakage. Once you linked against, say, 
5.6.0, you just kept 5.6.0 around, rather than trusting that 5.6.1 (or 
5.8.0) behaved the same as the version you were replacing.

Re: Apple Perl directory layout

[Chris Nandor]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Sherm Pendley) wrote:

> You were right. The CamelBones framework is linked against libperl, and 
> I've received numerous reports that CB apps continue to work untouched 
> after an upgrade to 5.6.1, which is binary-compatible.

An excellent reason to tell people to put perl in /usr/local/ (or similar)!

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/

Re: Apple Perl directory layout

[Dan Sugalski]

At 11:54 PM -0800 12/16/02, Wilfredo Sánchez wrote:


  As pointed out here, if Apple upgrades perl, you have probably to
upgrade XS modules.  But what I was thinking was that there might be
an application which embeds perl and therefore links against the
perl library.  A new system update with a new perl may require that
application to relink as well, if it uses API that changed in perl.
However, if the API was compatible, the app could continue to work.
This will never work, however, if the perl library moved location,
as that will cause a linker failure at runtime.  So my theory was
that breaking less often would be a good thing.


It's important to note that the directory structure was *not* meant
to deal with this sort of problem. What it was meant for was to
provide the ability to have multiple versions of perl installed
simultaneously as a means of preventing breakage. Once you linked
against, say, 5.6.0, you just kept 5.6.0 around, rather than trusting
that 5.6.1 (or 5.8.0) behaved the same as the version you were
replacing.

Perl didn't really have embedding in mind when that dir structure was
set--it's more targeted at extensions, and the assumption has always
been that embedders link against an explicit versioned libperl
library.

We're going to fix this for perl 6... ;)
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Apple Perl directory layout

[Sherm Pendley]

On Tuesday, December 17, 2002, at 02:54 AM, Wilfredo Sánchez wrote:


what I was thinking was that there might be an application which embeds 
perl and therefore links against the perl library.  A new system update 
with a new perl may require that application to relink as well, if it 
uses API that changed in perl.  However, if the API was compatible, the 
app could continue to work.

You were right. The CamelBones framework is linked against libperl, and 
I've received numerous reports that CB apps continue to work untouched 
after an upgrade to 5.6.1, which is binary-compatible.

sherm--

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

Re: Apple Perl directory layout

[Wilfredo Sánchez]

  Not related.  I caved in after getting hammered with protests for the 
Nth time via email for the horrible and evil decision I made way back 
when, not to version the directories.  :-)

  For what it's worth, my logic back then was:

  As pointed out here, if Apple upgrades perl, you have probably to 
upgrade XS modules.  But what I was thinking was that there might be an 
application which embeds perl and therefore links against the perl 
library.  A new system update with a new perl may require that 
application to relink as well, if it uses API that changed in perl.  
However, if the API was compatible, the app could continue to work.  
This will never work, however, if the perl library moved location, as 
that will cause a linker failure at runtime.  So my theory was that 
breaking less often would be a good thing.

  Anyway, this can still be done with symlinks, and perhaps that's a 
more flexible way to do it.

	-wsv


On Monday, December 9, 2002, at 12:05  PM, Christopher D. Lewis wrote:

I did file a bug via http://www.apple.com/macosx/feedback and 
subsequently, wsanchez apparently submitted a perl patch which leads 
to version-numbers in the pathname.
	--Chris

Re: Apple Perl directory layout

[Sherm Pendley]

On Wednesday, December 11, 2002, at 08:56 AM, Chris Nandor wrote:


works well for me, and I find no significant maintenance issues as 
outlined
by Sherm.

I 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.

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?

Re: Apple Perl directory layout

[Chris Nandor]

In article ,
 [EMAIL PROTECTED] (Dan Sugalski) wrote:

> At 1:42 AM -0500 12/10/02, Sherm Pendley wrote:
> >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.
> 
> FWIW, they generally are.

I don't believe this is true.  Usually they are installed in an 
*architecture*-agnostic location.

   [pudge@yaz pudge]$ perl -e 'printf "%s, %vd\n", $^O, $^V'
   linux, 5.8.0

   [pudge@yaz pudge]$ pmpath MP3::Info
   /usr/local/lib/perl5/site_perl/5.6.1/MP3/Info.pm

Then when you configure perl, you can choose to add older version 
directories:

   [pudge@yaz pudge]$ perl -MConfig -le 'print $Config{inc_version_list}'
   5.6.1 5.6.0 5.005

But this won't use the architecture-specific extensions under 
site_perl/$version/$arch, only the pure-perl ones found in 
site_perl/$version.

   [pudge@yaz pudge]$ perl -le 'print join "\n", @INC'
   /usr/local/lib/perl5/5.8.0/i686-linux
   /usr/local/lib/perl5/5.8.0
   /usr/local/lib/perl5/site_perl/5.8.0/i686-linux
   /usr/local/lib/perl5/site_perl/5.8.0
   /usr/local/lib/perl5/site_perl/5.6.1
   /usr/local/lib/perl5/site_perl/5.6.0
   /usr/local/lib/perl5/site_perl/5.005
   /usr/local/lib/perl5/site_perl
   .

So I still have access to my old pure perl modules with perl 5.8.0, and my 
old versions of perl still have access to their architecture-specific 
extensions, and I need to install new versions of those for perl 5.8.0.  The 
only problem I encounter here is if an old version of perl needs a new 
version of a module (architecture-specific or not) that has already been 
installed for perl 5.8.0; I need to install it back for each old version 
that needs it.  But since I rarely use the old versions, this is not a 
significant problem.

Everyone's entitiled to their opinion, especially when something is so tied 
to personal preference as this is.  But the default system as shown above 
works well for me, and I find no significant maintenance issues as outlined 
by Sherm.

However, I do find little fault with how Apple handles it, as I just prefer 
to install my own perl.  This is what I've learned to do on Debian Linux 
too, as installing your own perl over the system perl can cause havoc with 
apt-get etc.  There are certainly ways around it, but it's easier just to 
install into /usr/local/.

I think the biggest problem with how Apple does it is that it is 
nonstandard.  Every other platform does it with versions, that I am aware of 
(well, except for maybe MacPerl ).

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/

Re: Apple Perl directory layout

[Dan Sugalski]

At 1:42 AM -0500 12/10/02, Sherm Pendley wrote:

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.

FWIW, they generally are.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Apple Perl directory layout

[Sherm Pendley]

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?

Re: Apple Perl directory layout

[Chris Devers]

On Mon, 9 Dec 2002, Michael Maibaum wrote:

> On Monday, December 9, 2002, at 12:07 PM, John Siracusa wrote:
>
> > Apple's going to upgrade to perl 5.8.0?  I thought the plan was
> > "5.6.0 forever!" :P
>
>
> fair point, perhaps the plan is to remain at 5.6 till perl 6 arrives ;)

John already said that joke.

:)


-- 
Chris Devers  [EMAIL PROTECTED]
is actually not all that pessimistic
 about perl 6, and things that this
 good thing will be worth the wait,
 but it still makes a good target :)

Re: Apple Perl directory layout

[Peter N Lewis]

Is it really broken or is it different?  Lots of folks here just 
tend to install their version in the correct place and leave Apple's 
alone.  (I haven't yet but I will when I decide to upgrade to 
5.8.0.)  Perhaps Apple squashes bug reports like this because they 
see it not as "A bug, but a feature"

Actually, I did the reverse, I just trashed all of Apple's and 
installed 5.8 and I haven't had any problems.  Mind you I don't use a 
web server on the machines, so maybe all that funcky mod_perl stuff 
might not be broken, but then by the sounds of it reinstalling apache 
and mod_perl is a good idea anyway.

download & unpack tarball

./Configure -de [EMAIL PROTECTED] 
[EMAIL PROTECTED]
make
make test

remove:
~/.cpan
/Library/Perl
/System/Library/Perl
/Local/Library/Perl
/sw/lib/perl5

sudo make install

ln -s /Library/Perl /sw/lib/perl5

Note that you actually have to be a little more careful with the 
/sw/lib/perl5 directory if you have fink installed already as it 
installs a few modules there to start with and so you actually might 
have to merge them in.

Anyway, I'm sure what I'm doing is all a bad idea, but it has worked 
fine for me for a month or so.
   Peter.
--
  

Re: Apple Perl directory layout

[drieux]

On Monday, Dec 9, 2002, at 11:45 US/Pacific, [EMAIL PROTECTED] wrote:
[..]

Is it really broken or is it different?  Lots of folks here just tend 
to install their version in the correct place and leave Apple's alone.
[..]

Volks,

do people remember WHEN 'versioned' site_perl directories
became the hip-hop buzz cool thing?

Given that the cut over to 5.8.0 from 5.6 will require that
the non-pure-perl modules will need to be rebuilt, I'm not at
all sure what the 'issue' really is?

A part of the reason this is so 'not a bug' is that
other vendors, noteably Sun, also do an install into
their own 'private place' for the 'vendor supplied'
verion of perl, so that one can choose to either run
with 'vendor supplied, vendor supported' - or build
and install your own version.


ciao
drieux

---

Re: Apple Perl directory layout

[Michael Maibaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Monday, December 9, 2002, at 12:07 PM, John Siracusa wrote:


On 12/9/02 2:52 PM, Michael Maibaum wrote:

I think it is "really broken", for example, how is apple going to
upgrade Perl to 5.8 without it breaking for people who've installed XS
modules?


Apple's going to upgrade to perl 5.8.0?  I thought the plan was "5.6.0
forever!" :P




fair point, perhaps the plan is to remain at 5.6 till perl 6 arrives ;)


Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE99Ptiilk3LUlIL0MRAnJiAKDyYyV2bQtXVJYG5GhQR6X6FX9LhgCgv9tO
FfeF2Apemd4c1mDytc/oA8M=
=VQYA
-END PGP SIGNATURE-

Re: Apple Perl directory layout

[Christopher D . Lewis]

I did file a bug via http://www.apple.com/macosx/feedback and 
subsequently, wsanchez apparently submitted a perl patch which leads to 
version-numbers in the pathname.
	--Chris


On Monday, December 9, 2002, at 01:38  PM, Michael Maibaum wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


As I guess most of you know, Apple's system Perl layout is broken, 
because it doesn't version the module directories and this means Perl 
upgrade trauma. Anyway, I just found out that Apple has no bugs on 
this, there are no open, or it seems, closed bugs on the way perl is 
installed with the base system.

I'd like to encourage people to file a bug on this, so when apple 
upgrades the system Perl to 5.8.x they will hopefully use a sane 
directory layout

thanks

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE99PEmilk3LUlIL0MRAi5bAJsGxl11NGSlPcmvpVTXemIg/AsYAgCdHxrT
e3qD3ZW2FXBwcTa2XErXQcM=
=Dt1w
-END PGP SIGNATURE-

Re: Apple Perl directory layout

[Michael Maibaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Monday, December 9, 2002, at 12:12 PM, Sherm Pendley wrote:


On Monday, December 9, 2002, at 02:52 PM, Michael Maibaum wrote:


how is apple going to upgrade Perl to 5.8 without it breaking for 
people who've installed XS modules?

If *you* chose to install a copy of Perl 5.8 in a location where you 
are fully aware that it will be overwritten by a future Apple update, 
then whatever problems arise from *your* poor choice are your own 
fault. If you ask for problems, you have no right to complain about it 
when you get what you've asked for.


No, how is apple going to upgrade, not how am I, I have perl5.8 in 
/opt/local FWIW.

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE99Prvilk3LUlIL0MRArgQAJ9zhr3MqafYj4aH8tLsV8dF8erb9gCdHuhT
X5noOL7g5xKhXtN3SXL8QiM=
=kb31
-END PGP SIGNATURE-

Re: Apple Perl directory layout

[Michael Maibaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Monday, December 9, 2002, at 11:58 AM, [EMAIL PROTECTED] wrote:




- Original Message -
From: Michael Maibaum <[EMAIL PROTECTED]>
Date: Monday, December 9, 2002 2:52 pm
Subject: Re: Apple Perl directory layout

SNIP

I think it is "really broken", for example, how is apple going to
upgrade Perl to 5.8 without it breaking for people who've
installed XS
modules?

SNIP

But doesn't that break anyway?  When I went from 5.6.1 to 5.8.0 I had 
to redo all my modules.  I'm not sticking up for Apple and their weird 
install plan.  I'm just wondering if they don't see their Perl as a 
problem.



well, sure you have to recompile the XS modules, but you don't have to 
hunt through to find and erase them first. Pure Perl modules shouldn't 
be an issue.

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE99Pm9ilk3LUlIL0MRAtaPAKDMVxNL5n6TNslrjLYuxYI9PMMZiwCg2T3Z
ztbFX6NbclX1Uf5BeO7DEXY=
=yc56
-END PGP SIGNATURE-

Re: Apple Perl directory layout

[Sherm Pendley]

On Monday, December 9, 2002, at 02:52 PM, Michael Maibaum wrote:


how is apple going to upgrade Perl to 5.8 without it breaking for 
people who've installed XS modules?

If *you* chose to install a copy of Perl 5.8 in a location where you are 
fully aware that it will be overwritten by a future Apple update, then 
whatever problems arise from *your* poor choice are your own fault. If 
you ask for problems, you have no right to complain about it when you 
get what you've asked for.

sherm--

UNIX: Where /sbin/init is Job 1.

Re: Apple Perl directory layout

[John Siracusa]

On 12/9/02 2:52 PM, Michael Maibaum wrote:
> I think it is "really broken", for example, how is apple going to
> upgrade Perl to 5.8 without it breaking for people who've installed XS
> modules?

Apple's going to upgrade to perl 5.8.0?  I thought the plan was "5.6.0
forever!" :P

(maybe it's just taking 3 years to compile... ;)
-John

Re: Apple Perl directory layout

[ellem]

- Original Message -
From: Michael Maibaum <[EMAIL PROTECTED]>
Date: Monday, December 9, 2002 2:52 pm
Subject: Re: Apple Perl directory layout

SNIP
> I think it is "really broken", for example, how is apple going to 
> upgrade Perl to 5.8 without it breaking for people who've 
> installed XS 
> modules?
SNIP

But doesn't that break anyway?  When I went from 5.6.1 to 5.8.0 I had to redo all my 
modules.  I'm not sticking up for Apple and their weird install plan.  I'm just 
wondering if they don't see their Perl as a problem.

Re: Apple Perl directory layout

[Sherm Pendley]

On Monday, December 9, 2002, at 02:38 PM, Michael Maibaum wrote:


As I guess most of you know, Apple's system Perl layout is broken


Please don't presume to speak for everyone here. What I *know* is that's 
it's different than the traditional layout. Whether or not it's "broken" 
is a matter of opinion, not a statement of fact.

, because it doesn't version the module directories and this means Perl 
upgrade trauma.

Upgrading Perl can be traumatic, but only if you choose to make it so. 
If that's what you choose to do, you're asking for headaches, and you 
shouldn't blame Apple when you get what you've asked for.

Personally, I think the default approach of organizing everything under 
/usr/local/lib/perl/ is bizarre. If you're a fan of it, try this 
exercise - spend a few years maintaining and updating multiple versions 
of Perl, installing them with the default layout. Then, see how long it 
takes you to identify and delete modules that are three or four 
revisions old. You'll be able to do it - but not without quite a bit of 
thought and some careful hand-pruning of subdirectories.

It's far saner to just install each version of Perl into its own 
directory - /usr/local/perl5.8.0 or whatever. With a minimum of thought 
and planning, it's trivially simple (and not the least bit traumatic) to 
keep as many different versions of Perl on your system as you need. And 
deleting an old version that's no longer used becomes a trivial matter 
of deleting the proper directory.

 Anyway, I just found out that Apple has no bugs on this


Because it's not a bug. Bugs are unintentional flaws; this was an 
intentional decision. You're free to disagree with it if you want, of 
course, but not everything you disagree with is a mistake.

I'd like to encourage people to file a bug on this, so when apple 
upgrades the system Perl to 5.8.x they will hopefully use a sane 
directory layout

And I'd like to encourage people not to file erroneous bug reports. If 
anything, file a feature request - but even that, in my opinion, is 
misguided. The directory layout that Apple has chosen for their system 
copy of Perl is perfectly reasonable.

What is *un*reasonable, in my opinion, is to expect Apple to ship an OS 
that continues to work perfectly in all respects when you replace a 
major component. What makes this all the more unreasonable is the fact 
that it's trivially simple to install a copy of Perl elsewhere, for your 
own use, while still allowing the OS and anything else that expects the 
default version to continue to use that.

sherm--

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

Re: Apple Perl directory layout

[Michael Maibaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Monday, December 9, 2002, at 11:45 AM, [EMAIL PROTECTED] wrote:




- Original Message -
From: Michael Maibaum <[EMAIL PROTECTED]>
Date: Monday, December 9, 2002 2:38 pm
Subject: Apple Perl directory layout


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


As I guess most of you know, Apple's system Perl layout is broken,
because it doesn't version the module directories and this means
Perl
upgrade trauma.


Is it really broken or is it different?  Lots of folks here just tend 
to install their version in the correct place and leave Apple's alone. 
 (I haven't yet but I will when I decide to upgrade to 5.8.0.)  
Perhaps Apple squashes bug reports like this because they see it not 
as "A bug, but a feature"


I think it is "really broken", for example, how is apple going to 
upgrade Perl to 5.8 without it breaking for people who've installed XS 
modules?


Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE99PRpilk3LUlIL0MRAgSdAJ9Po5mZmyLY29luQC6KVZYhX7/nmgCdGfnz
q2jW7/RMoe4171I/K4alflw=
=TvYg
-END PGP SIGNATURE-

Re: Apple Perl directory layout

[ellem]

- Original Message -
From: Michael Maibaum <[EMAIL PROTECTED]>
Date: Monday, December 9, 2002 2:38 pm
Subject: Apple Perl directory layout

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
> As I guess most of you know, Apple's system Perl layout is broken, 
> because it doesn't version the module directories and this means 
> Perl 
> upgrade trauma. 

Is it really broken or is it different?  Lots of folks here just tend to install their 
version in the correct place and leave Apple's alone.  (I haven't yet but I will when 
I decide to upgrade to 5.8.0.)  Perhaps Apple squashes bug reports like this because 
they see it not as "A bug, but a feature"

Apple Perl directory layout

[Michael Maibaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


As I guess most of you know, Apple's system Perl layout is broken, 
because it doesn't version the module directories and this means Perl 
upgrade trauma. Anyway, I just found out that Apple has no bugs on 
this, there are no open, or it seems, closed bugs on the way perl is 
installed with the base system.

I'd like to encourage people to file a bug on this, so when apple 
upgrades the system Perl to 5.8.x they will hopefully use a sane 
directory layout

thanks

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE99PEmilk3LUlIL0MRAi5bAJsGxl11NGSlPcmvpVTXemIg/AsYAgCdHxrT
e3qD3ZW2FXBwcTa2XErXQcM=
=Dt1w
-END PGP SIGNATURE-