[126720] trunk/dports

[David Evans]

On 10/14/14 9:23 AM, Craig Treleaven wrote:
> Re: [126720] trunk/dports
> At 7:16 AM -0700 10/14/14, devans at macports.org wrote:
>>
>>     Revision
>>
>>
>>     126720 <https://trac.macports.org/changeset/126720>
>>
>>     Author
>>
>>
>>     devans at macports.org
>>
>>     Date
>>
>>
>>     2014-10-14 07:16:52 -0700 (Tue, 14 Oct 2014)
>>
>> *Log Message*
>> binary dependents of libcdio: increment revision to rebuild with 
>> latest libcdio, libiso9660 after recent upgrade of libcdio.
>> *Modified Paths*
>>
>>   * trunk/dports/emulators/mednafen/Portfile
>>   * trunk/dports/gnome/gstreamer010-gst-plugins-ugly/Portfile
>>   * trunk/dports/gnome/gstreamer1-gst-plugins-ugly/Portfile
>>   * trunk/dports/multimedia/vcdimager/Portfile
>>   * trunk/dports/multimedia/xine-lib/Portfile
>>
>
> Thanks.  I'm relatively newish to MacPorts.  I wondered if revbumps 
> were necessary for some of the updates I put through yesterday.  For 
> libcdio, I thought specifically that it was a minor update and 
> wouldn't require bumps.  How did you determine the revbumps were, in 
> fact, required?
>
> Craig
Generally, these problems will show up in rev-upgrade if you have the 
dependents of the library in question installed.  In the case of 
libcdio, the library versioning was incremented for both libcdio and 
libiso9660 so that they no longer matched the file names expected at 
link time.  This can be detected by comparing the library file names 
before and after the upgrade.

Note that in the case of libdvdnav, although the library version numbers 
did not change, rev-upgrade -d showed libdvdnavmini.4.dylib missing and 
apparently libdvdnavmini is not provided any more by the updated port.

Could not open /opt/local/lib/libdvdnavmini.4.dylib: Error opening or 
reading file (referenced from /opt/local/bin/mplayer)
DEBUG: Marking /opt/local/bin/mplayer as broken
--->  Found 1 broken file(s), matching files to ports
--->  Found 1 broken port(s):
      mplayer2 @2.0-20131009
          /opt/local/bin/mplayer

In addition, there are API changes that break the build of mplayer2 so 
that a rev-bump is not sufficent.
See https://trac.macports.org/ticket/45387

Dave




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20141014/9cf65cf8/attachment.html>