Mimic FreeBSD ports in handling perlocal.pod - was Re: perllocal.pod conflict

[markd at macports.org]

"Didier Arenzana" <darenzana at gmail.com> on Thursday, June 7, 2007 at 11:44
AM -0800 wrote:
>while trying to install port rrdtool, I encountered the following
>error in the 'activating' step :
>
>--->  Activating rrdtool 1.2.23_0
>Error: Target com.apple.activate returned: Image error:
>/opt/local/lib/perl5/5.8.8/darwin-2level/perllocal.pod is being used
>by the active frozenbubble2 port.  Please deactivate this port first,
>or use the -f flag to force the activation.
>Warning: the following items did not execute (for rrdtool):
>com.apple.activate
>Error: Status 1 encountered during processing.
>
>I did a little googling, it appears that the 'perllocal.pod' file
>purpose is to contain the list of locally-installed perl modules not
>installed with the standard distribution.
>
>I guess that when installing frozenbubble2, it did create the file,
>and now rrdtool tries to replace it with its own version. The correct
>behaviour would be to update the file appending new contents to it,
>shouldn't it?
>
>During the build phase, I see the fllowing :
>Appending installation info to
>/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_net_rrdtool/work/destroot/opt/local/lib/perl5/5.8.8/darwin-2level/perllocal.pod
>
>So the port is creating the perlloca.pod in its working directory, and
>tries to copy it over the original one in the activation phase. Is
>there a way to fix that?
>
>Regards,
>Didier Arenzana

This occurs with a number of perl ports.  The only way I know of to deal
with it is to force the activation and overwrite perllocal.pod.  (port -f
activate rrdtool)  Looks like we'd need to do something similar to what
FreeBSD ports do for a longer term solution.

http://lists.freebsd.org/pipermail/freebsd-perl/2005-June/000666.html

Mark