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

Orville Bennett illogical1 at gmail.com
Sat Mar 7 10:15:20 PST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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 :-)

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.

>
>
> What the commit is supposed to fix is the following case:
>
> foo depends on bar.
> You already have bar 1.0 installed but you don't have foo installed.
> bar 1.2 is available in the ports tree.
> Prior to this commit, if you "port install foo", the latest version  
> of foo gets installed but bar remains at 1.0.
> The latest version of foo may not be compatible with bar 1.0 but  
> should be compatible with the latest version of bar, 1.2.
> After this commit, if you "port install foo", bar first gets updated  
> to 1.2, then foo gets installed.
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkmyubgACgkQ2yWVgjgEOKRkBwCeOyYZ+v51T+1JJgKi1h8Br57a
LqkAoIF/USDN+tSZVqFsuF8onu2FxAFP
=pfT8
-----END PGP SIGNATURE-----


More information about the macports-dev mailing list