Re: On "fixing" Perl core modules "in place"

The guy did wrong, that's obvious, but I think it indicates a procedural/permissions problem with your development setup also.

Developer's working on multi-user systems and servers should not be able to update system-wide library files. Any and all changes to shared libraries should only be possible from an account specifically charged with systems admin resposibilities. And only after testing has been signed-off.

There should be no need for a developer to have write access to /usr/lib/perl5/*. Even if a developer is specifically charged with modifying a module that normally lives in that pathtree, it is quite easy for him to work on a copy of the module in a private path located ahead of the system path, for his account only.

Once he is satisfied with his changes, the copy should go through at least a minimal regression testing against your existing applications in some sort of test server environment before being signed-off for deployement into shared library trees.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re: On "fixing" Perl core modules "in place" Download Code


Clear questions and runnable code get the best and fastest answer
	PerlMonks