[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