Well, actually I tried to send email to the maintainer of Logfile::Rotate to see if he would be interested in adding this features to the package. Unfortunately the email bounced...

Did you try his CPAN address? That's different from the one in the module.

This actually raises what is to me an interesting question. What to do when your work uses an open source module whose author is either not able or willing to make the modifications you would like, or disappears completely so cannot make any patches at all?

Here we have branched a couple of modules where the authors were unresponsive or dismissive of our changes. So now we use a custom version of MIME::Lite and Config::Inifile the former because Eryq doesnt answer mails and hasn't updated the module (despite posted bugfixes) in two years, and the latter because despite providing patches the authors decided they didn't want the functionality we needed. This means that for these modules we use our own distributions, which is annoying but better than doing a complete rewrite to utilize a supported module.

After conversations with a number of Open Source types lately Ive been seriously thinking about hijacking MIME::Lite until the author returns to Perldom. In fact we were contemplating a "CPAN Orphanage", perhaps a sourceforge project for all the CPAN modules whose authors have abandonded them.

So I guess the relevent point to you is that if you want a patched Logfile::Rotate and you cant get the author to integrate the change, then fork it and use your local copy anyway. If the author isn't maintaining the module anyway I dont see any reason not to.

Another approach is to subclass the module, or intercept calls. For a work project, I wasn't happy with the Pod::Html output, so I hacked in some changes that vary depending on the version:

sub per_version {
  if ($Pod::Html::VERSION eq '1.01') {
    # perl5.005_03
    *Pod::Html::process_text2 = \&Pod::Html::process_text1;
    undef *Pod::Html::process_text1;
    *Pod::Html::process_text1 = \&my_process;
    @options = qw/ --recurse --header /;
  } elsif ($Pod::Html::VERSION =~ /^1\.0[34]$/) {
    # perl-5.6.0, 5.6.1, 5.8.0
    *Pod::Html::process_L2 = \&Pod::Html::process_L;
    undef *Pod::Html::process_L;
    *Pod::Html::process_L = \&my_oldprocess;
    @options = qw/ --recurse /;
  } else {
    die "Don't know how to hack Pod::Html v$Pod::Html::VERSION\n";
}

sub my_process ($$;$$) {
  my($lev, $rstr, $func, $closing) = @_;
  my $closer = '>' x (($closing||0) + 1);
  if ($func && $func eq 'L') { 
    # suppress 'the ... manpage' markup
    $$rstr =~ s{^ 
      ^ ( \w+ (?: ::\w+ )* )
      (?: -(?!$closer)> (\w+) )?
      (.*?) (\s* $closer)
    }{
      defined($2) ? qq{$1-E<gt>$2$3|$1/"item_$2$4} : "$1$3|$1$4"
    }xe;
  }
  Pod::Html::process_text2($lev, $rstr, $func, $closing);
}

sub my_oldprocess {
  my($str) = @_;
  $str =~ s,^(\w+(::\w+)*)$,$1|$1/,;
  Pod::Html::process_L2($str);
}
[download]

This approach isn't always the right one, but it's a useful tool to have.

Hugo

I did something like this at the beginning. I set up patches for MIME::Lite and then included the patches in the distribution for my code. When makefile.pl ran it would check the version of MIME::Lite and if it was unpatched (turns out that MIME::Lites version string doesnt compare properly) it would apply the patch first. The problem is that I work on Win32 so having patch handy wasnt guarenteed, yada yada. In the end it was much simpler just to modify the released version and include it directly. Although overriding existing subs with new code never occured to me I admit.

Incidentally are you aware of any CPAN policy for unmaintained modules? Is there a "takeover" mechanism available or not? Have the senior Perl people ever discussed this?

---
demerphq

I like the idea of a CPAN Orphanage. It might be as simple as adding a "Perl Modules" category to the Unmaintained Free Software Project.

-Blake

This actually raises what is to me an interesting question. What to do when your work uses an open source module whose author is either not able or willing to make the modifications you would like, or disappears completely so cannot make any patches at all?

Well, in my case it happened with Radius::Packet and Radius::Dictionary. I added support for vendor-specific attributes but was unable to make the author update the code. Finally, I decided to steal the module while maintaining full credits to the original author. My revised distribution now lives in Net::Radius. I hope my work is doing justice to the excellent work of the original author...

For other things, we just keep a collection of patches around. I always try to let the author know about the patches and in almost all cases, I've had luck. Sometimes the problem lies in contacting the author, for which the CPAN addresses are very useful. In fact I just got a nice hint a couple of posts above.

Best regards

-lem, but some call me fokat