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
that
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
need
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
version.
I do not think we need to change the MacPorts error message from the
one that is currently being printed. It is accurate.
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
