On Wed, 2012-12-26 at 14:41 -0600, Todd Rinaldo wrote: > Yes we have realized this was a problem and have taken steps to change > the default behavior to be compatible with upstream in our upcoming > major release (11.36) of cPanel, tentatively in January. For this upcoming release, do you intend to base those changes on the current version of Storable as it exists in core perl, or to deviate further from your 2.25-derived Storable? As I see it, you have three options: a) Apply more changes atop your current customized Storable, releasing it as Storable with some version > 2.39_01. b) Work in conjunction with p5p to merge your changes into core perl's Storable, and stop maintaining a separate 2.25-derived fork of Storable. c) Release your updated version of 2.25-derived Storable, but named with a different package name (cPanel::Storable or similar). Any option _other_ than (a) means that users of Perl can no longer trust the version numbers of core modules of perl to have consistent functionality, due to your releases. Option (b) is clearly a preferable option, of course, and I am curious what led to you choosing option (a) in the past. If you must fork Storable, changing the namespace (c) at least means that you do not cause issues for innocent bystanders. > I'm sorry for the RT noise and possibly wasted research. If you will > give me a list offline of the CPAN RT tickets, I'll be happy to reply > with my 2 cents. To be clear, these are not problems being reported on the CPAN RT, but rather organizations that have installed their own RT in a cPanel environment. Because of the update, their installs of RT no longer function correctly. In fact, with Storable 2.39_01, many CPAN packages fail to even _install_, due to (correctly) failing tests. - AlexThread Previous | Thread Next