I'll ask this again since I never got an answer the last time.

Why isn't this fix included with Perl 5.6.0? I suspect that "the fix" is included but that the release of Perl 5.6.x broke part of the fix so that the problem has reappeared.

My (often fuzzy) memory recalls this chronology:

• "CPAN suddenly upgrading Perl" bug fixed and it required both changes to the CPAN.pm module and to some features of the CPAN itself (the collection of web/ftp servers).
• Reports of people upgrading just CPAN.pm and the problem going away.
• Reduced frequency of reports of this problem
• Release of Perl 5.6.0
• Increase in frequency of reports again

BTW, I did do some work trying to check this on my own. In particular, the latest (according to search.cpan.org) CPAN.pm's ChangeLog file says nothing of this fix (and hasn't been updated since March 1999).

I'd dig deeper but I never use CPAN.pm myself and am only interested in this bug as it relates to being able to help others when they run into this problem. (:

My personal memory goes as follows.

Perl 5.005_03 released with (IIRC) version 1.48. This version will upgrade perl if it sees something that depends on Perl 5.6.x, but that fact not realized because Perl 5.6.x doesn't exist.

Perl 5.6.0 released.

Not too long thereafter while trying to install something I find that it is upgrading perl on me. I send a bug report. Andreas sends me back a "sorry" and a patch that will die horrible flaming death instead of doing the upgrade. I wasn't the first to complain, that honor goes to Joseph Hall.

A bit after that I am installing some new machines, and trying to load a ton of modules from the old ones. The "die flaming death" aspect of things causes me grief so I convinced Adreas that he wants to make it skip that upgrade and anything which depends on it, but continue installing other things. (I might have sent him a patch that did that, I don't think so though.)

Fast-forward to the present. Anyone who has a machine with an install of 5.005_03 who has not upgraded their CPAN from the default install, upon requiring any module which requires Perl 5.6.x, will upgrade Perl. Painfully. This problem is cropping up and will continue to crop up because more and more modules over time are requiring Perl 5.6.x.

And so a plea to any module authors. Please think very, very carefully before making your module require something that involves 5.6.x. When you do that you are adding to this problem. Furthermore if you have a module which is used by other modules, and you introduce that dependency, then you have made all of those other modules also cause this problem. Please consider carefully the convenience to yourself versus the inconvenience of causing people to have Perl upgrade itself on them.

Yes, the bug is in a version of a module released with Perl 5.005_03. But that version of Perl is still widely used. And it will, despite its best attempts to uninstall itself, continue to be for some time to come.

Thanks for the added info. Some clarification...

The original complaint in this thread is from someone who has Perl 5.6.0 not 5.005_03. So the patch came after 5.6.0 and it is 5.6.1 that will come with a fixed CPAN.pm?

I think 5.6.0 existed for a very long time during much of which I ignored its existance and that is a major problem with my recall of the timeline.

Also, I recall another reason that CPAN.pm would decide to upgrade Perl was that the newest version of the module being requested is the one shipped with Perl (vs. that the module listed Perl vX.Y.Z as a dependancy). That is the piece that I'm worried was rebroken.

So I'm still a little curious if this has really been fixed. So it would really be nice if the original noder would let us know if upgrading CPAN fixed the problem. I think I'll /msg them... (:

        - tye (but my friends call me "Tye")

Ok -- it worked like a charm -- trick was to upgrade CPAN only -- don't "install Bundle::CPAN" Thanks a lot for the prompt help.
_______________________________________________
"Intelligence is a tool used achieve goals, however goals are not always chosen wisely..."