On Jan 21, 2011, at 12:20 PM, Daniel J. Luke wrote:

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.

Why would we have a different default behavior "port upgrade outdated" then for "port upgrade port1"?

Does one need the -R "port -R upgrade" to build dependents?

-R would be the fix for this case.

Why are the effects of -R not the default behavior?

From "man port":
     -n       don't upgrade dependencies (affects upgrade and install)
-R also upgrade dependents (only affects upgrade) - note that this does not upgrade dependents' dependencies

could be:
     -n       don't upgrade dependencies (affects upgrade and install)
     -N      don't upgrade dependents (affects upgrade and install)

This seems like a better default behavior. I'm sure I'm missing something.

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.

It seems even if there was no rev bump that we would want to rebuild dependent ports except probably depends_build.

--
Brad
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev

Reply via email to