Hi Craig,
Thanks for the clarification around the behaviour of "die" and how to avoid
it.
>> Of course that is one approach, but seeing that someone has gone to all
>> the trouble of 'packetizing' perl it is a shame.
>>
>> Surely in the 'open source' space one is never sure whether one's open
>> source based application is going to work with a new version of, in this
>> case perl, especially if one has compiled additional modules. So it would
>> make sense, to let you switch environments, from old to new and back again.
>> The way the PCSI works for perl at the moment, has become a nugatory
>> activity.
>I was dismayed when I prepared the 5.20 kits to discover that it removed
>the 5.18 installation. I looked long and hard in the docs for a way to make
>that optional and never found anything. If someone knows of a way to do
>that with PCSI, please fill me in.
PCSI is great for installing stuff into VMS$COMMON. As soon as you stray
from that it gets trickier.
>The difficulty here is that, for example, 5.18.2 really should remove
>5.18.1 before installing because (by default) they go in the same directory,
>but 5.20.0 should not remove 5.18.x. The only way I can see to do that with
>PCSI is to include the version number in the product name, so the product
>name, instead of "PERL," would be "PERL518," "PERL520," etc. This is what
>HP has done with Java, where you have "JAVA150" and "JAVA60." I guess the
>earliest that could happen now would be for 5.22 next March.
I would be happy with that.
>Of course there is no requirement to use the PCSI kits. People can build
>from source and install wherever they like.
Your release announcement should include a pointer to the source files (even
if it's the vanilla CPAN site).
Thanks for your good work!
Jeremy Begg
