Daniel J. Luke
dluke at geeklair.net
Fri Jan 21 12:20:53 PST 2011
On Jan 21, 2011, at 3:04 PM, Bradley Giesbrecht wrote:
> On Jan 21, 2011, at 10:45 AM, Dan Ports wrote:
>> Implicit in here is the assumption that you're always upgrading all of
>> your outdated ports at once -- `port upgrade outdated`.
>> If you saw a new version of libpng and decided you wanted to upgrade
>> it (for all of the exciting new features a graphics library can offer?)
>> but not all your other ports, `port upgrade libpng` would happily let
>> you do that and leave most of your system broken.
> Is this how port currently works?
yes, port does allow you to shoot yourself in the foot if you want to (and in this case, I don't think it warns you, as it probably should).
> If "outdated" is a "pseudo-portname" then wouldn't it more or less expanded to "port upgrade [port1 port 2 port3 etc...]"?
> I would think there would not be any difference in the way "port upgrade" follows the dependency tree when upgrading a single port vs outdated.
there's no dependency tree in this case.
> Does one need the -R "port -R upgrade" to build dependents?
-R would be the fix for this case.
It's libA has a new version that is incompatible with the old version. progB depends on libA.
Normally you would do 'port upgrade outdated' and get a new libA with a new progB linked against the new libA.
If you do 'port upgrade libA' you will get a new libA and you will have broken progB.
I'm not sure if we currently track enough information in the registry to warn in this case (and we probably can't get complete coverage), but if would be nice if we could store the compatibility version for libs and warn in cases where the user is going to break their install.
Daniel J. Luke
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
More information about the macports-dev