Perl error, once and for all
ryandesign at macports.org
Wed Feb 25 23:53:47 PST 2009
On Feb 26, 2009, at 01:44, Scott Haneda wrote:
> On Feb 25, 2009, at 9:51 PM, Eric Hall wrote:
>>> That feels dirty to me, why not just -f all p5 installs then? If
>>> is the real solution, why not have ports look for p5 and auto add
>>> the -
>>> f? I am sure this is a bad idea, but if this is the norm, users are
>>> more or less going to do this anyway. What are the risks?
>>>> Really, the port should output a note letting you know that you
>>>> to do this (and/or we should just decide to order @INC like freebsd
>>>> ports does so that we don't have to deal with it any more.).
>> Yes, and this is going to happen... RSN.
>> For some (if not all) of the p5-* ports that have recently
>> sprouted problems, its the man pages that are the issue, not the
>> modules themselves. I haven't had a chance to look into what
>> can be done to avoid the man page collisions.
>> Forcing the install with -f isn't the right solution.
>> It "works" as a band-aid for now, but its not a good thing.
> How can you tell it is a man page collision? Here is a pretty
> consistant error I see:
> Error: Target org.macports.activate returned: Image error: /opt/
> local/lib/perl5/5.8.9/Test/Builder/Module.pm is being used by the
> active perl5.8 port. Please deactivate this port first, or use the -
> f flag to force the activation.
> Some, yes, I see man pages, and I feel a lot better about -f'ing
> them. This one, I just braved it, and did not know the repercussions.
Note that you will only be told about the first collision. There may
be untold subsequent collisions about which you're not informed until
you -f the activation, at which point it's a bit late to change it.
In most cases, you do not want to use the -f flag with MacPorts. With
the p5 modules it is currently sometimes necessary, see below.
> Is this saying, the new port I am installing, has in it
> "Module.pm", and is trying to write over /opt/local/lib/perl5/5.8.9/
> Test/Builder/Module.pm ? If that is the case, would it not be
> acceptable to version check the to be installed, against the
> already installed. If they are equal, move on, that is graceful.
> If they are not equal, I am not sure what to do, logically, you
> could ask the user to figure it out, that seems half baked.
> Picking the newest version seems dangerous. Leaving it alone,
> seems problematic. Installing it elsewhere, and hooking your
> currently installed port into it would be acceptable, if that is
> even possible.
MacPorts operates under the assumption that exactly one port will
provide a file at a given path. The combination of perl5.8 and
whatever module it is that you were installing that wanted to install
Test/Builder/Module.pm is in violation of that assumption. Sometimes
this occurs because perl5.8 didn't used to include a particular
module (hence a separate port was created) but now due to a version
update perl5.8 does already include that module (making the separate
port unnecessary). Sometimes the separate port may provide a newer
I do not think we need to change the MacPorts error message from the
one that is currently being printed. It is accurate.
More information about the macports-users