libpng transition?

[Bradley Giesbrecht]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110121/e73b3bb0/attachment-0001.html>