More upgrade

David Evans devans at macports.org
Mon May 11 15:17:10 PDT 2009


Ryan Schmidt wrote:
>
> On May 5, 2009, at 22:46, Frank J. R. Hanstick wrote:
>
>>     Fontforge installed with the deactivate.  I while back, I raised 
>> the issue of deactivating and/or uninstalling ports before 
>> upgrading.  Since then, I have run into four ports that have required 
>> the deactivation before hand.  The number seems to be increasing.  
>> Maybe some things need to be rethought.
>
> By all means. If you have specific ideas for what could be changed in 
> base to fix this, please share them on macports-dev.
>
> I posted an idea and some thoughts and questions about this topic 
> there a month ago to which nobody responded:
>
> http://lists.macosforge.org/pipermail/macports-dev/2009-April/008148.html
>
> I am still interested in feedback on that message.
>
 From what I have seen, while this general type of problem has popped up 
in several ports, the specific solution is often port specific and depends
on what the upstream developer thought was "standard" usage.  In open 
source development, this is often a statement of personal preferences.

For example, some might think it is "standard" to uninstall a port 
before attempting to install a new version.

So I think the idea that a single global change in MacPorts would do 
away with this sort of problem entirely without causing problems
elsewhere is a bit optimistic.  While these problems look similar, the 
specific fix often involves evaluation of the specific occurance.  And
standard usage is in the eye of the beholder -- developer actually.

A simple example that I ran across today is gimp-gap-devel.   In this 
port, if ffmpeg-devel is installed, the build of an internal copy of ffmpeg
fails because the port lists (accidentally) a MacPorts include path 
before the internal include path in its build.  Thus the MacPorts 
(incompatible)
include files are used and build fails due to conflicting symbol 
definitions. The MacPorts path came from the pkgconfig defined include 
path for glib which was ordered first in the include path list.  The 
solution was to move the local include paths to the front of the list.   
See r50862, r50863.

evolution-data-server is a much harder problem as it uses a very 
complicated build system so its much harder to track down exactly
what behavior is causing the problem and therefore where the correct 
change should be made.

At any rate, these are problems that need to be tracked down and fixed 
one by one.  And the magnitude of the task is not too great if we are
only talking about 4 ports out of almost 6000.

Dave






More information about the macports-users mailing list