Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re^2: why I will not use ActiveState again

by gisle (Novice)
on Dec 01, 2006 at 23:18 UTC ( #587333=note: print w/replies, xml ) Need Help??

in reply to Re: why I will not use ActiveState again
in thread Getting Fed Up with ActiveState

You'll find the following note in the ActivePerl ChangeLog:
* File::Path's rmtree() function has been replaced to address security vulnerability CAN-2005-0448.

We have basically adopted the version from Debian Linux.

BTW, we also publish this patch file that documents how the current ActivePerl differs from the official 5.8.8.

  • Comment on Re^2: why I will not use ActiveState again

Replies are listed 'Best First'.
Re^3: why I will not use ActiveState again
by rjbs (Pilgrim) on Dec 02, 2006 at 14:02 UTC
    Unfortunately, when someone comes to me and says, "Your module produces errors or warnings on my ActivePerl install," it's difficult for me to determine that it's because a core module several layers up the chain is different. I certainly don't want to consult that patch file for every recursively included module. The changed rmtree didn't just address some vulnerability, it introduced at least one new behavior, carping on [] as the first arg to rmtree. With a core that doesn't behave like the perl core, it's harder to support. The changes may be minor, but they're distracting and make debugging take significantly longer where it shouldn't, liked in pure Perl modules. As someone who tries to support every platform, I find it very frustrating.
      it's difficult for me to determine that it's because a core module several layers up the chain is different

      I think that point of yours (along with the rest of your post) is fair enough. And I also think that ActiveState's decision to modify the module is fair enough.

      So ... let's get constructive about the issue ... what should they be doing (from the perspective of a module author) when they perceive a need to amend a core module ?


        Duh. You change the version number whenever you allow a change to any module to escape your tight little grasp.

        In the case of emergency changes, try to change the version number in a way that won't conflict with the next version that the real author of the module is likely already working on and will be releasing soon, before he notices that you've upgraded out of his control. I usually do this by incrementing by a smaller-than-usual amount (such as appending "001" to the end).

        - tye        

        what should they be doing (from the perspective of a module author) when they perceive a need to amend a core module

        My two cents, At a minimum, make sure any thing that dies/carps mentions that it's a patched version of the module and bump/alter the version number. Better would be to get the patch taken upstream -- or, in this case, perhaps, get File::Path pulled out as a dual core/CPAN module so the patch could be made generally available in the "latest" release of the module on CPAN.


        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://587333]
[Corion]: While working on WWW::Mechanize:: Chrome, I had the suspicion that AnyEvent was doing something wrong, but I was able to swap it out for Mojolicious and the error persisted.
[Corion]: Of course, the error was in my own code ;)
[marioroy]: Corion, start and start_child in MCE::Hobo::Manager return a MCE::Hobo object, whereas P::FM returns the PID. I can have it return the PID though. I tried Hobo::Manager with several P::FM modules, just changed P::FM to MCE::Hobo::Manager and it works.
[marioroy]: I also have a Hobo driver for Forklift allowing folks to use in multiple classes, no conflicts with one another. That's not possible for P::FM.
[Discipulus]: congrats marioroy!
[marioroy]: CORE::wait works well eventhough multiple instances or classes using Hobo::Manager.
[Corion]: marioroy: I'm not sure what the normal use for the PID is in P:FM, but I guess that most programs just ignore or log it
[Corion]: Oh, yes, programs could call wait $pid, but if your $pid is an object, then you could add a ->wait method to it and wait $pid would call that automatically "thanks" to indirect object notation
[marioroy]: Just documentation edits is all that remains. Hobo::Simple provides foreach and forseq with identifier capability -- all transparently supporting array, hash, file handle, and seq 1 .. N.
[marioroy]: Corion Regarding PID, that's great. So will leave it so compatible with MCE::Hobo. e.g. ->create returns a Hobo object. Folks can get ->pid from it. So, that's not a problem.

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (7)
As of 2017-05-26 08:42 GMT
Find Nodes?
    Voting Booth?