transfer /opt/local to another machine

[j. van den hoff]

thanks to both of you for your answers and clarifications.

On Mon, 13 Apr 2015 04:04:14 +0200, Ryan Schmidt <ryandesign at macports.org>  
wrote:

>
> On Apr 12, 2015, at 5:54 AM, j. van den hoff wrote:
>
>> I just have upgraded two x86_64 machines from 10.9. to 10.10.3 and  
>> upgraded one of them according to the migration guide (i.e.  
>> uninstalled/reinstalled all ~ 800 macports packages). this took an  
>> astonishing long time (over night, basically) partly due to a  
>> multi-hour recompilation of the `atlas' library. and that was on the  
>> faster machine with an SSD...
>
> This is intentional, because atlas is performance-sensitive, so the port  
> is deliberately programmed to not use precompiled binaries from our  
> build server, and to instead build on your computer. My understanding is  
> that the build process builds atlas many times, with different compiler  
> settings, then tries out each one to see which one is actually fastest  
> on your particular computer, then installs that one. That's why it takes  
> so long.

yes, I understand that. I'm not sure, however, how much of a performance  
hit I will see when using the intel core-i7 optimized binary on an intel  
core 2 duo, so I just would try it out, whether it's OK for my use (that  
would mean via `octave', which I am using only sporadically, so ...).

>
>
>> one marginal observation I made: after `port deactivate installed' when  
>> executing `port installed active' I receive the message "None of the  
>> specified ports are installed." which probably should read "None of the  
>> specified ports are active." or "No ports are active.".
>
> The message is correct. You ran the "installed" command, and as an  
> argument you specified the list of ports you wanted installation details  
> for, namely, the list of active ports. The list of active ports is  
> empty, so it is correct, in a way, for MacPorts to say that none of the

I guessed so much.

> zero ports specified are installed. If anything, the message could be  
> clarified to read "No ports were specified" or maybe "The list of  
> specified ports is empty."

that what be somewhat better, yes. but actually I think it would be  
clearer to handle these pseudo-portnames (possibly on a per case basis, if  
needed) in the messages. I guess that currently the message generating  
code only gets the list of ports to which the pseudo-portname expands? for  
instance, right now I _do_ have 2 inactive ports (which, by the way,  
magically reappeared (were downloaded etc) during the `port installed  
activate' run of the migration procedure (specifically these two: llvm-3.5  
@3.5.1_3 and  SuiteSparse @4.2.1_3+atlas+gcc48) -- no precise idea why  
this happens (in fact they were there inactive in the first place so I  
trashed them in the initial phase of the migration. that they "reappear"  
seems to indicate that they are required, despite being inactive??).

so, with these 2 inactive ports I get the message for `port installed  
inactive':

The following ports are currently installed:
   llvm-3.5 @3.5.1_3
   SuiteSparse @4.2.1_3+atlas+gcc48

this seems equally misleading to me as the "no ports are installed  
message" when there are no inactive ports at all. if the report generator  
would keep track of the entered pseudo-portname the message seemingly  
could easily be clarified to

The following ports are currently installed and {port pseudo-portname  
here}.

another question regarding the manpage and `port help' output: `installed'  
and `(in)active' are both listed as pseudo-portnames expanding to the list  
of denoted ports. this sure is true for `port installed' and `port  
outdated', e.g. but not so for most of  the others, such as `port  
(in)active' which interpret these words as (unknown actions).  what is  
wrong: the documentation or my understanding of it?

>
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/