Support for MacPorts users

Scott Haneda | 25 Feb 2009 06:49

Perl error, once and for all

Sorry, I know this has been explained before, bur I can not find the  
answer:

DEBUG: Executing org.macports.activate (p5-mime-base64)
--->  Activating p5-mime-base64  <at> 3.07_0
Error: Target org.macports.activate returned: Image error: /opt/local/ 
share/man/man3/MIME::Base64.3pm.gz is being used by the active perl5.8  
port.  Please deactivate this port first, or use the -f flag to force  
the activation.
Warning: the following items did not execute (for p5-mime-base64):  
org.macports.activate
Error: The following dependencies failed to build: p5-mime-base64 p5- 
net-ip
Error: Status 1 encountered during processing.

Looking for why this happens, and how to solve it.

--
Scott

* If you contact me off list replace talklists <at>  with scott <at>  *

headers

Daniel J. Luke | 25 Feb 2009 16:03

Re: Perl error, once and for all

On Feb 25, 2009, at 12:49 AM, Scott Haneda wrote:
> Sorry, I know this has been explained before,

yes, very recently.

> bur I can not find the answer:
>
> DEBUG: Executing org.macports.activate (p5-mime-base64)
> --->  Activating p5-mime-base64  <at> 3.07_0
> Error: Target org.macports.activate returned: Image error: /opt/ 
> local/share/man/man3/MIME::Base64.3pm.gz is being used by the active  
> perl5.8 port.  Please deactivate this port first, or use the -f flag  
> to force the activation.

As the error says, you want to use -f to activate in this case.

Really, the port should output a note letting you know that you need  
to do this (and/or we should just decide to order  <at> INC like freebsd  
ports does so that we don't have to deal with it any more.).

--
Daniel J. Luke
+========================================================+
| *---------------- dluke <at> geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+

(Continue reading)

headers

Scott Haneda | 25 Feb 2009 22:21

Re: Perl error, once and for all

On Feb 25, 2009, at 7:03 AM, Daniel J. Luke wrote:
> On Feb 25, 2009, at 12:49 AM, Scott Haneda wrote:
>> Sorry, I know this has been explained before,
>
> yes, very recently.

Can you point me to they "why", not just the solution, I want to  
understand what is the problem?

>> bur I can not find the answer:
>>
>> DEBUG: Executing org.macports.activate (p5-mime-base64)
>> --->  Activating p5-mime-base64  <at> 3.07_0
>> Error: Target org.macports.activate returned: Image error: /opt/ 
>> local/share/man/man3/MIME::Base64.3pm.gz is being used by the  
>> active perl5.8 port.  Please deactivate this port first, or use the  
>> -f flag to force the activation.
>
> As the error says, you want to use -f to activate in this case.

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  <at> INC like freebsd  
> ports does so that we don't have to deal with it any more.).

I think I just found the trac on this, and read it, it is ancient,

(Continue reading)

headers

Eric Hall | 26 Feb 2009 06:51

Re: Perl error, once and for all

On Wed, Feb 25, 2009 at 01:21:38PM -0800, Scott Haneda wrote:
> On Feb 25, 2009, at 7:03 AM, Daniel J. Luke wrote:
> >On Feb 25, 2009, at 12:49 AM, Scott Haneda wrote:
> >>Sorry, I know this has been explained before,
> >
> >yes, very recently.
> 
> Can you point me to they "why", not just the solution, I want to  
> understand what is the problem?
> 
> >>bur I can not find the answer:
> >>
> >>DEBUG: Executing org.macports.activate (p5-mime-base64)
> >>--->  Activating p5-mime-base64  <at> 3.07_0
> >>Error: Target org.macports.activate returned: Image error: /opt/ 
> >>local/share/man/man3/MIME::Base64.3pm.gz is being used by the  
> >>active perl5.8 port.  Please deactivate this port first, or use the  
> >>-f flag to force the activation.
> >
> >As the error says, you want to use -f to activate in this case.
> 
> 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  <at> INC like freebsd  
> >ports does so that we don't have to deal with it any more.).

(Continue reading)

headers

Vincent Lefevre | 1 Mar 2009 03:34

Re: Perl error, once and for all

On 2009-02-26 05:51:33 +0000, Eric Hall wrote:
> 	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.

The man pages could be installed in a separate directory. And MacPorts
would just need to set up $prefix/etc/man.conf accordingly.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

headers

Scott Haneda | 26 Feb 2009 08:44

Re: Perl error, once and for all

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  <at> 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.

(Continue reading)

headers

Ryan Schmidt | 26 Feb 2009 08:53

Re: Perl error, once and for all


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  <at> 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

(Continue reading)

headers

Scott Haneda | 26 Feb 2009 09:20

Re: Perl error, once and for all

On Feb 25, 2009, at 11:53 PM, Ryan Schmidt wrote:
>> 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.

Ok, so if I am getting this, perl5.8 has a module already installed  
and the p5 I want to put is in also trying to put it in.  This is the  
core conflict?

Which one do you chose is the issue?

At the very least, let me chose, but the -f can force things to happen

(Continue reading)

headers

Ryan Schmidt | 26 Feb 2009 09:26

Re: Perl error, once and for all


On Feb 26, 2009, at 02:20, Scott Haneda wrote:

>> 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.
>
> Ok, so if I am getting this, perl5.8 has a module already installed  
> and the p5 I want to put is in also trying to put it in.  This is  
> the core conflict?

I believe that is correct, yes.

> Which one do you chose is the issue?

There are a few p5 ports that print messages advising users to force  
the activation of the p5 port. This would cause the p5 port's module  
to overwrite the perl5.8 port's module. The assumption is that the p5  
port provides a newer version.

> At the very least, let me chose, but the -f can force things to  
> happen even deeper down the chain, and it would be a bear to back  
> out of those.
>

(Continue reading)

headers

Scott Haneda | 26 Feb 2009 13:28

Re: Perl error, once and for all

On Feb 26, 2009, at 12:26 AM, Ryan Schmidt wrote:
> On Feb 26, 2009, at 02:20, Scott Haneda wrote:
>>> 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.
>>
>> Ok, so if I am getting this, perl5.8 has a module already installed  
>> and the p5 I want to put is in also trying to put it in.  This is  
>> the core conflict?
>
> I believe that is correct, yes.
>
>> Which one do you chose is the issue?
>
> There are a few p5 ports that print messages advising users to force  
> the activation of the p5 port. This would cause the p5 port's module  
> to overwrite the perl5.8 port's module. The assumption is that the  
> p5 port provides a newer version.

Probably a mostly safe assumption.  But there will be those edge  
cases.  Newer is not always better and I would be willing to bet,  
there are some newer modules that break backwards functionality.  I  
suppose that is the reason why this is not a simple issue to solve.

(Continue reading)

headers

Vincent Lefevre | 1 Mar 2009 03:53

Re: Perl error, once and for all

On 2009-02-26 04:28:46 -0800, Scott Haneda wrote:
> I think you have to modify the module to "use lib" and supply a path.   

No need to do that. Just modify PERL5LIB in your environment once and
for all (you or MacPorts had to do the same for $PATH, $LIBRARY_PATH,
$C_INCLUDE_PATH or whatever, anyway). RTFM.

> Does anyone know how CPAN solves this?

CPAN lets the user choose where he wants to install things.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

headers

Scott Haneda | 1 Mar 2009 10:00

Re: Perl error, once and for all

On Feb 28, 2009, at 6:53 PM, Vincent Lefevre wrote:
> On 2009-02-26 04:28:46 -0800, Scott Haneda wrote:
>> I think you have to modify the module to "use lib" and supply a path.
>
> No need to do that. Just modify PERL5LIB in your environment once and
> for all (you or MacPorts had to do the same for $PATH, $LIBRARY_PATH,
> $C_INCLUDE_PATH or whatever, anyway). RTFM.

So, let me get this straight, if MacPorts was to install a .profile  
with a certain PERL5LIB env var in it, this issue is solved?
--
Scott

* If you contact me off list replace talklists <at>  with scott <at>  *

headers

Vincent Lefevre | 2 Mar 2009 01:18

Re: Perl error, once and for all

On 2009-03-01 01:00:43 -0800, Scott Haneda wrote:
> So, let me get this straight, if MacPorts was to install a .profile with 
> a certain PERL5LIB env var in it, this issue is solved?

Yes, but MacPorts should not override the user's settings (i.e. it
should test whether PERL5LIB is already set...). One should end up
with something like:

if [ -n "$PERL5LIB" ]; then
  PERL5LIB="${PERL5LIB}:/opt/local/lib/perl5/vendor_perl"
else
  export PERL5LIB
  PERL5LIB="/opt/local/lib/perl5/vendor_perl"
fi

Also, the modules that overwrite the core modules should be fixed.

But there's still the potential problem with binaries and man pages,
though. But a directory /opt/local/perl5 can be used for that. Adding
/opt/local/perl5/bin to $PATH just before /opt/local/bin would be
sufficient.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

headers

Vincent Lefevre | 2 Mar 2009 02:11

Re: Perl error, once and for all

On 2009-03-02 01:18:41 +0100, Vincent Lefevre wrote:
> Yes, but MacPorts should not override the user's settings (i.e. it
> should test whether PERL5LIB is already set...). One should end up
> with something like:
> 
> if [ -n "$PERL5LIB" ]; then
>   PERL5LIB="${PERL5LIB}:/opt/local/lib/perl5/vendor_perl"
> else
>   export PERL5LIB
>   PERL5LIB="/opt/local/lib/perl5/vendor_perl"
> fi

BTW, the order can also be changed at build time. I don't know how
to do this, but I haven't searched closely...

Also, a 7-year-old thread on  <at> INC search order was resurrected
a couple of weeks ago:

  http://www.nntp.perl.org/group/perl.perl5.porters/2009/02/msg144185.html

> Also, the modules that overwrite the core modules should be fixed.
> 
> But there's still the potential problem with binaries and man pages,
> though. But a directory /opt/local/perl5 can be used for that. Adding
> /opt/local/perl5/bin to $PATH just before /opt/local/bin would be
> sufficient.

Concerning the man pages, I'm not so sure. As I've said in another
mail, the suffix (a.k.a. man section) is different, meaning that
there would be no conflicts, but this may depend on the modules.

(Continue reading)

headers

Bradley Giesbrecht | 3 Mar 2009 16:30

Re: Perl error, once and for all

On Mar 1, 2009, at 5:11 PM, Vincent Lefevre wrote:

> On 2009-03-02 01:18:41 +0100, Vincent Lefevre wrote:
>> Yes, but MacPorts should not override the user's settings (i.e. it
>> should test whether PERL5LIB is already set...). One should end up
>> with something like:
>>
>> if [ -n "$PERL5LIB" ]; then
>>  PERL5LIB="${PERL5LIB}:/opt/local/lib/perl5/vendor_perl"
>> else
>>  export PERL5LIB
>>  PERL5LIB="/opt/local/lib/perl5/vendor_perl"
>> fi

My path to p5's looks like this:
	/opt/local/lib/perl5/vendor_perl/5.8.9/

Wouldn't the full path including the version dir need to be added to  
PERL5LIB?

Are you suggesting using this in Portfiles?

If so I guess we would need to test for which version of perl is  
active and then set the path.

Could a macports perl5 port group do that?

If I have perl5.8 active and install a p5 and then deactivate perl5.8  
and activate perl5.10 should I expect my p5 to be active and functional?

(Continue reading)

headers

Vincent Lefevre | 3 Mar 2009 16:55

Re: Perl error, once and for all

On 2009-03-03 07:30:18 -0800, Bradley Giesbrecht wrote:
> On Mar 1, 2009, at 5:11 PM, Vincent Lefevre wrote:
>>> if [ -n "$PERL5LIB" ]; then
>>>  PERL5LIB="${PERL5LIB}:/opt/local/lib/perl5/vendor_perl"
>>> else
>>>  export PERL5LIB
>>>  PERL5LIB="/opt/local/lib/perl5/vendor_perl"
>>> fi
>
> My path to p5's looks like this:
> 	/opt/local/lib/perl5/vendor_perl/5.8.9/
>
> Wouldn't the full path including the version dir need to be added to  
> PERL5LIB?

I don't know whether this has changed in Perl 5.8.9 (I haven't
upgraded yet), but with previous versions, the version dir should
not be used in $PERL5LIB, as perl automatically adds the paths so
that modules installed with previous versions can still be used.
For instance:

$ perl -V
[...]
  %ENV:
    PERL5LIB="/Users/vinc17/lib/site_perl:/opt/local/lib/perl5/vendor_perl"
   <at> INC:
    /Users/vinc17/lib/site_perl/darwin-2level
    /Users/vinc17/lib/site_perl
    /opt/local/lib/perl5/vendor_perl/5.8.8/darwin-2level
    /opt/local/lib/perl5/vendor_perl/5.8.8

(Continue reading)

headers

Bradley Giesbrecht | 3 Mar 2009 20:49

Re: Perl error, once and for all


On Mar 3, 2009, at 7:55 AM, Vincent Lefevre wrote:

> On 2009-03-03 07:30:18 -0800, Bradley Giesbrecht wrote:
>> On Mar 1, 2009, at 5:11 PM, Vincent Lefevre wrote:
>>>> if [ -n "$PERL5LIB" ]; then
>>>> PERL5LIB="${PERL5LIB}:/opt/local/lib/perl5/vendor_perl"
>>>> else
>>>> export PERL5LIB
>>>> PERL5LIB="/opt/local/lib/perl5/vendor_perl"
>>>> fi
>>
>> My path to p5's looks like this:
>> 	/opt/local/lib/perl5/vendor_perl/5.8.9/
>>
>> Wouldn't the full path including the version dir need to be added to
>> PERL5LIB?
>
> I don't know whether this has changed in Perl 5.8.9 (I haven't
> upgraded yet), but with previous versions, the version dir should
> not be used in $PERL5LIB, as perl automatically adds the paths so
> that modules installed with previous versions can still be used.
> For instance:
>
> $ perl -V
> [...]
>  %ENV:
>    PERL5LIB="/Users/vinc17/lib/site_perl:/opt/local/lib/perl5/ 
> vendor_perl"
>   <at> INC:

(Continue reading)

headers

Vincent Lefevre | 6 Mar 2009 23:15

Re: Perl error, once and for all

On 2009-03-03 11:49:12 -0800, Bradley Giesbrecht wrote:
> Maybe we could add a port "macports-profile" that would be a script  
> similar to:
> /opt/local/share/macports/setupenv.bash

Yes, this is a rather standard way of doing such things.

> I suppose the file /opt/local/etc/maports_profile.conf could be looked  
> for and if found could be parsed for overrides and additions.

I would call it "/opt/local/etc/profile".

> I have a macports on my laptop that I'm keeping clean just to help  
> resolve this perl5 issue. I hope we can come up with a work solution  
> soon. Even if it's just the decision to instruct users to add PERL5LIB  
> to their .profile by hand.
>
> Oh, and what about other shells? Let that small base work it out  
> themselves as they are probably used to doing?

Isn't the .profile sourced at login time, so that all shells inherit
its environment?

Otherwise the user should probably source his .profile from the right
init file of his shell (e.g. .zprofile in case of zsh), unless he has
specific configuration.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>

(Continue reading)

headers

Bradley Giesbrecht | 1 Mar 2009 06:35

Re: Perl error, once and for all

On Feb 28, 2009, at 6:53 PM, Vincent Lefevre wrote:

> On 2009-02-26 04:28:46 -0800, Scott Haneda wrote:
>> I think you have to modify the module to "use lib" and supply a path.
>
> No need to do that. Just modify PERL5LIB in your environment once and
> for all (you or MacPorts had to do the same for $PATH, $LIBRARY_PATH,
> $C_INCLUDE_PATH or whatever, anyway). RTFM.

This is the MacPorts Users list. Right?

So just who are MacPorts Users? I know next to nothing about perl. But  
I use it everyday because it's everywhere.

I just want to install something that needs a perl and a p5 module. Do  
I really need to RTFM for that?

If I want to install a something written in C of C++ should I just RTFM?

Now if your talking to port authors you may have a point but even then  
I don't understand why the perl5 port wouldn't set necessary env's up  
for me.

When you compile on your own to /usr/local or where ever you get an  
understanding of the process and the environment that you just don't  
get from "port install perl5".

Seeing as "port install perl5" is supposed to easier then downloading  
perl sources and winging it on ones own it's only understandable that

(Continue reading)

headers

Vincent Lefevre | 2 Mar 2009 01:57

Re: Perl error, once and for all

On 2009-02-28 21:35:59 -0800, Bradley Giesbrecht wrote:
> I just want to install something that needs a perl and a p5 module. Do I 
> really need to RTFM for that?

MacPorts can do things for you or tell you what to do. Otherwise, yes,
you should RTFM. But this is not specific to perl...

> If I want to install a something written in C of C++ should I just RTFM?

This is a good example. MacPorts installs headers in /opt/local/include
and libraries in /opt/local/lib, and these are not standard locations
searched by compilers not installed by MacPorts (such as Apple's gcc
from Xcode). And it seems that MacPorts does not change the .profile to
declare these locations. So, if you want to install a C or C++ program
that needs such headers/libraries, you must tell it where to find them.

> I have a question. Why are there man pages for perl modules that are not 
> installed?

I'm not sure. I've also noticed that man pages from modules do not have
the same suffix (e.g. "3" instead of "3pm").

> Why do I have to -f an install to install a p5?

You shouldn't.

>>> Does anyone know how CPAN solves this?
>>
>> CPAN lets the user choose where he wants to install things.
>

(Continue reading)

headers

Scott Haneda | 1 Mar 2009 10:20

Re: Perl error, once and for all

On Feb 28, 2009, at 9:35 PM, Bradley Giesbrecht wrote:
> On Feb 28, 2009, at 6:53 PM, Vincent Lefevre wrote:
>> On 2009-02-26 04:28:46 -0800, Scott Haneda wrote:
>>> I think you have to modify the module to "use lib" and supply a  
>>> path.
>>
>> No need to do that. Just modify PERL5LIB in your environment once and
>> for all (you or MacPorts had to do the same for $PATH, $LIBRARY_PATH,
>> $C_INCLUDE_PATH or whatever, anyway). RTFM.
>
> This is the MacPorts Users list. Right?

Hey, that's a good point, while off topic, are the questions I am  
asking about port creation in general better suited to some other list?

> So just who are MacPorts Users? I know next to nothing about perl.  
> But I use it everyday because it's everywhere.
>
> I just want to install something that needs a perl and a p5 module.  
> Do I really need to RTFM for that?

You my friend, are hitting the nail right on the head from my  
perspective.  I do not at all mind this discussion from portfile devs,  
and port devs in general. You have to think about the kid who want to  
install wireshark, to learn about his network, or troubleshoot  
something.  Maybe a bad example, we all know what they want wireshark  
for :)

The goal should be, for 99% of MacPorts users, to not know what -d -v - 
f clean, distclean etc are for.  At least, that is largely my

(Continue reading)

headers

Joshua Root | 1 Mar 2009 10:43

Re: Perl error, once and for all

Scott Haneda wrote:
> I have seen many posts, where a
> port is not installing.  The reply from other users has been "you need
> to -f it, some ports are just that way", and that is not the right info,
> it will spiral out of control, to the point where as illustrated above,
> they blindly -f things.  -f is for when you know what you are doing, it
> should not be propagating as a solution.

You should've seen the situation pre-1.7. You had to use -f half the
time to uninstall old inactive versions of ports. And yes, some users
ended up blindly using -f for everything, sometimes with undesired
consequences.

We are getting better, slowly but surely. 

What the perl situation needs is someone who understands the issue to
just get in and get the job done. The ticket has well and truly hit
maintainer timeout by now.

- Josh

headers

Scott Haneda | 1 Mar 2009 11:23

Re: Perl error, once and for all

On Mar 1, 2009, at 1:43 AM, Joshua Root wrote:
> Scott Haneda wrote:
>> I have seen many posts, where a
>> port is not installing.  The reply from other users has been "you  
>> need
>> to -f it, some ports are just that way", and that is not the right  
>> info,
>> it will spiral out of control, to the point where as illustrated  
>> above,
>> they blindly -f things.  -f is for when you know what you are  
>> doing, it
>> should not be propagating as a solution.
>
> You should've seen the situation pre-1.7. You had to use -f half the
> time to uninstall old inactive versions of ports. And yes, some users
> ended up blindly using -f for everything, sometimes with undesired
> consequences.
>
> We are getting better, slowly but surely. 

Indeed, and this dialogue is always good.

> What the perl situation needs is someone who understands the issue to
> just get in and get the job done. The ticket has well and truly hit
> maintainer timeout by now.

Thanks Josh, this is the first I have sort of gotten the impression  
the issue is even know how to be solved. I assume the ticket was so  
old was that no one could come to a consensus as to the best way to  
solve it, making it more political.

(Continue reading)

headers

Daniel J. Luke | 26 Feb 2009 16:16

Re: Perl error, once and for all

On Feb 26, 2009, at 7:28 AM, Scott Haneda wrote:
> Does anyone know how CPAN solves this?

CPAN installs overwrite the perl-provided module with the newer one  
(this is the whole reason why we have a problem).

--
Daniel J. Luke
+========================================================+
| *---------------- dluke <at> geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
|   Opinions expressed are mine and do not necessarily   |
|          reflect the opinions of my employer.          |
+========================================================+

On Feb 26, 2009, at 7:28 AM, Scott Haneda wrote:
> Does anyone know how CPAN solves this?

CPAN installs overwrite the perl-provided module with the newer one  
(this is the whole reason why we have a problem).

--
Daniel J. Luke
+========================================================+
| *---------------- dluke <at> geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+

(Continue reading)

headers

Vincent Lefevre | 1 Mar 2009 03:59

Re: Perl error, once and for all

On 2009-02-26 10:16:23 -0500, Daniel J. Luke wrote:
> On Feb 26, 2009, at 7:28 AM, Scott Haneda wrote:
>> Does anyone know how CPAN solves this?
>
> CPAN installs overwrite the perl-provided module with the newer one  
> (this is the whole reason why we have a problem).

Well, that's a MacPorts specific bug, then. Under Debian, it defaults
to /usr/local, thus does *not* overwrite perl-provided modules from
Debian (that would be really bad if it did). Anyway, the user can
choose. The documentation for path configurations sucks, but that's
possible.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

headers

Bradley Giesbrecht | 1 Mar 2009 07:09

Re: Perl error, once and for all

Quoting some freebsd'ers:
http://forums.freebsd.org/showthread.php?t=2031

I have freeBSD 7.0 installed.
I've updated my perl installation from perl5-8-8 tu perl5.8.9
is it possible to upgrade all installed perl modules from ports using  
a one single command ?

> Well, there is a command called perl-after-upgrade, which should do  
> that. However, me and some other people here have found that that  
> isn't always panning out, so following perl-after-upgrade with  
> portupgrade -f p5* (or the portmaster counterpart of that) is  
> advisable.

Damn -f :)

//Brad

headers

Bradley Giesbrecht | 1 Mar 2009 06:47

Re: Perl error, once and for all

On Feb 28, 2009, at 6:59 PM, Vincent Lefevre wrote:

> On 2009-02-26 10:16:23 -0500, Daniel J. Luke wrote:
>> On Feb 26, 2009, at 7:28 AM, Scott Haneda wrote:
>>> Does anyone know how CPAN solves this?
>>
>> CPAN installs overwrite the perl-provided module with the newer one
>> (this is the whole reason why we have a problem).
>
> Well, that's a MacPorts specific bug, then. Under Debian, it defaults
> to /usr/local, thus does *not* overwrite perl-provided modules from
> Debian (that would be really bad if it did). Anyway, the user can
> choose. The documentation for path configurations sucks, but that's
> possible.

I have to guess that this is the issue. /usr/local is considered safe  
as should be. Macports doesn't have /opt/local/usr/local. Oh, maybe it  
does, I didn't check.

I don't know enough about where perl, cpan or modules get installed to  
offer anything good here but I think having a perl5 "base" and  
installing everything else somewhere else might make sense. I wish I  
knew more about perl. Well, no, I really don't. I just want to use  
perl based programs.

Perl guru's, please save us from -f :) You can do it :)

//Brad

(Continue reading)

headers

Vincent Lefevre | 26 Feb 2009 04:02

Re: Perl error, once and for all

On 2009-02-25 13:21:38 -0800, Scott Haneda wrote:
> That feels dirty to me, why not just -f all p5 installs then?

No! Any port that needs -f is broken.

Note: -f is dangerous. It can trash your system. And it is not
compatible with activate/deactivate.

--

-- 
Vincent Lefèvre <vincent <at> vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

headers

Mark Hattam | 25 Feb 2009 16:21

Re: Perl error, once and for all


On 25 Feb 2009, at 15:03, Daniel J. Luke wrote:

> On Feb 25, 2009, at 12:49 AM, Scott Haneda wrote:
>> Sorry, I know this has been explained before,
>
> yes, very recently.
>
>> bur I can not find the answer:
>>
>> DEBUG: Executing org.macports.activate (p5-mime-base64)
>> --->  Activating p5-mime-base64  <at> 3.07_0
>> Error: Target org.macports.activate returned: Image error: /opt/ 
>> local/share/man/man3/MIME::Base64.3pm.gz is being used by the  
>> active perl5.8 port.  Please deactivate this port first, or use the  
>> -f flag to force the activation.
>
> As the error says, you want to use -f to activate in this case.
>
> Really, the port should output a note letting you know that you need  
> to do this (and/or we should just decide to order  <at> INC like freebsd  
> ports does so that we don't have to deal with it any more.).
>
> --
> Daniel J. Luke

The error says to EITHER deactivate perl5.8 OR use the -f flag ...  
(similar to the xorg problem a couple of days ago) ... which should  
you choose? How do you know which to choose?

(Continue reading)

headers

Daniel J. Luke | 25 Feb 2009 17:39

Re: Perl error, once and for all

On Feb 25, 2009, at 10:21 AM, Mark Hattam wrote:
>>> DEBUG: Executing org.macports.activate (p5-mime-base64)
>>> --->  Activating p5-mime-base64  <at> 3.07_0
>>> Error: Target org.macports.activate returned: Image error: /opt/ 
>>> local/share/man/man3/MIME::Base64.3pm.gz is being used by the  
>>> active perl5.8 port.  Please deactivate this port first, or use  
>>> the -f flag to force the activation.
>>
>> As the error says, you want to use -f to activate in this case.
>>
>> Really, the port should output a note letting you know that you  
>> need to do this (and/or we should just decide to order  <at> INC like  
>> freebsd ports does so that we don't have to deal with it any more.).
>
> The error says to EITHER deactivate perl5.8 OR use the -f flag ...  
> (similar to the xorg problem a couple of days ago) ... which should  
> you choose?

In this case, you can google for the port name and deactivate and find  
the answer, or realize that in order to actually use that perl module  
you'll need to have perl installed and active, so deactivating perl5.8  
isn't the right answer.

> How do you know which to choose?

I agree that the port should output a message letting you know what to  
do (for now, and longer term, we need to make it so you don't need to  
force activate these kinds of perl modules).

--

(Continue reading)

headers

Scott Haneda | 25 Feb 2009 22:25

Re: Perl error, once and for all

On Feb 25, 2009, at 8:39 AM, Daniel J. Luke wrote:

>> How do you know which to choose?
>
> I agree that the port should output a message letting you know what  
> to do (for now, and longer term, we need to make it so you don't  
> need to force activate these kinds of perl modules).

I want to add some criticism, but hope you all take it as  
constructive, as that is what is meant wholeheartedly.

I am not a new ports user.  I think I have made 40 ports or so, in one  
way or another, and done well more than that on installs.  I am new,  
and beginner, but not a just downloaded and trying to use it user.

If I were really a new user, I would have long since left macports,  
feeling the app makes my system unclean, dangerous, and mysterious.   
If I have to come to a list to get a p5 installed, as a new users, I  
probably wouldn't.  Solving this, will put ports forward in the eyes  
of the new user, getting more people to speak nicely of it.

I have been on a ISP to use it, they tried it once, and will not touch  
it, I have no idea why specifically, but I would bet something like  
this is related.

Thanks for all your help everyone, I do love ports a lot, despite the  
razors :)
--
Scott

(Continue reading)