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

[diotalevi]

You're being unfair or you're not describing what kind of fix it was. Perhaps his bug fix should have been integrated into core perl but hadn't yet. If that's true, fix it in place and send the patch to p5p. I do that all the time to my own system. Lately that's how B::Lint has been progressing - I fix it locally in my own installation and the changes get kicked up to p5p.

[johngg]

I think the OP described a "fix" that didn't even compile. Perhaps "fix" is the wrong word here? The "fix", so called, doesn't sound like something that should be integrated into core Perl to me.

Cheers,

JohnGG

[Fletch]

Perhaps "fix" is the wrong word here?

I took it in a veterinary sense (your pet doesn't "work" too well in some ways after you get them "fixed" either :).

[tlm]

What was done could be described as a "bug fix" only if we expand the definition of "bug" to include something like "an error message that is confusing to the naive user". Given that, as I pointed out, CGI::Carp messages are arguably not meant for the eyes of naive users in the first place, the justification for this particular "fix" was exceedingly slim.

For a single-user system, the approach you describe is probably fine, but, IMO, for multi-user systems the patch should be sent first to the maintainers, and have the fixed version come back as a standard distribution. In the meantime, I patch the version in my privlib and leave everything in /usr/lib/perl5 untouched. After all, "shadowing" of the untouched original version by the patched version in privlib (through a suitable definition of PERL5LIB) works like a charm.

[diotalevi]

For a single-user system, the approach you describe is probably fine, but, IMO, for multi-user systems the patch should be sent first to the maintainers, and have the fixed version come back as a standard distribution.

You're full of it. You can make changes to system libraries before and independantly of the vendor if you document it and make a plan for dealing with this disparity between your system and the rest of the world. You can do what I recommended which was to get that change into the official version or you can maintain your forked version. Either way, it isn't forbidden. It's not a good idea and it's a last resort kind of thing. Doesn't mean it isn't occasionally necessary.

I see that you want to get approval for the idea that it's never ok to change a system library like this guy did. Sure. That's fine. He broke production and didn't bother to test, notify the other users, or get their approval. That deeply, deeply sucks. It doesn't mean it should be impossible for him to write patches. Assuming the guy grows a brain next week and learns how to write valid code and it comes to pass that a core library has a bug, it really might make sense for the thing to be patched.

[bunnyman]

How many other users are affected by your change? How many other programmers? Just you?

If there are other programmers affected, do you notify them in advance so they can be aware of possible issues? Can you be sure you won't cause problems for production services?

It sounds like your own installation is your own personal development playground. That is the correct place to make these types of changes. Production installations should be treated with care, and any changes should be well-tested and well-publicized.

[diotalevi]

How many other users are affected by your change?

Everyone that's going to use the next version of perl whether as a user, developer, or admin. Oh wait, you meant the change that's local that hasn't roundtripped through p5p? I haven't found reason to patch a core module on the production systems but it wouldn't be forbidden if there weren't some better alternative like a newer, fixed version. We're probably in agreement that it'd be really far down on the list of things to try when working around a problem.