[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