libpng transition?

Jack Howarth howarth at bromo.med.uc.edu
Fri Jan 21 13:09:35 PST 2011


On Fri, Jan 21, 2011 at 03:20:53PM -0500, 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.
> 
> > 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.
> 

What insures that libpng is built before packages which depends-lib
on port:libpng if both are currently installed (at older versions
or revisions) when 'port outdated' is executed. Without an explicit
version/revision dependency field attached to the each depends-lib
entry, I don't see how that can happen. Or are you saying the port
repeats the dependency mapping on 'port outdated' even if the package
is already installed (and hence the dependency already satisfied)?
                   Jack

> 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.          |                          
> +========================================================+
> 
> 
> 
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev


More information about the macports-dev mailing list