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