[47756] trunk/base/src/macports1.0/macports.tcl

Ryan Schmidt ryandesign at macports.org
Sat Mar 7 10:29:27 PST 2009


On Mar 7, 2009, at 12:15, Orville Bennett wrote:

> On Mar 7, 2009, at 2:34 AM, Ryan Schmidt wrote:
>
>> On Mar 6, 2009, at 15:37, Orville Bennett wrote:
>>
>>> Is there some check which ensures that upgrading the dependency  
>>> doesn't break the app that's updated?
>>
>> I don't understand the scenario. Could you give an example?
>
> You've compiled A and B.
> B gets upgraded in macports to a version which no longer works  
> properly with A.
> A also gets updated but still doesn't work with the new B.
> If port upgrade A is done the new B gets upgraded too and A no  
> longer works properly/compiles.
> B is boost if anyone was trying to guess :-)

If you want to upgrade A without upgrading B, use "sudo port -nf  
upgrade A"


> This is why I use 'port install' to "upgrade" to new software.  
> Upgrade deletes the old version then installs the newer version.  
> Being bitten by this in the past, I rather use port install which  
> puts the newer versions into a new slot so I can test that they  
> work together.
> It would be awesome if macports made it so that this wasn't  
> necessary though.

"sudo port upgrade A" does not uninstall the old version of A.

"sudo port -u upgrade A" does.

If you don't want the old version to be uninstalled when you upgrade,  
don't use the -u flag.

Caveat: "sudo port -nf upgrade A" does uninstall the old version of A.



More information about the macports-dev mailing list