If I'm misunderstanding you or you have a better approach which doesn't involve running the code, please let me know. (Hmm, creating local test suites targeting external modules?)

What I was thinking off was something like this. If Bar::foo(N) has a bug where it dies where N=0, when it should just return -1, then I might only apply my patch where eval { Bar::foo(0) } == -1 is false.

Of course this relies on whatever broken behaviour we're looking for being cheap to test for with no side effects. Make vague sense?

That makes perfect sense, but the problem isn't what the code is currently doing. The problem is that we don't know what the code will do in the future.

Cheers,
Ovid

New address of my CGI Course.

If what the code is currently doing is not a problem, then you don't have a problem, do you?

I think you misstated something here. I guess you are trying stress your vexation anticipating his fix clobbering your fix and that that future is not coming soon enough. This indicates a basic trust issue with the code you are using. You imply the module doesn't have versions, if it does, don't waste time generalizing your solution. Instead, for the modules you care about, report the bug of lack of versions. You need to be able to divine the version of things to maintain the control/quality/efficiency standards which you seek.

Within the limitations he describes, adrianh's solution is suited to your problem.

What are the problems with forking? If you have hope that the author will be back someday, you can do it quietly by renaming the packages and distributing them within your distribution. So long as you hope, you treat the code as if it were still under its author's care. If he wakes up or comes back or finds time, you can refactor the code easily at your convenience. If it turns out the code is abandoned, it will be nice that you kept it alive.

Be well,
rir