[MacPorts] #51689: preserve_runtime_libraries convenience PortGroup

MacPorts noreply at macports.org
Wed Jun 22 10:40:52 PDT 2016


#51689: preserve_runtime_libraries convenience PortGroup
-------------------------+--------------------------------
 Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
     Type:  submission   |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  contrib      |    Version:
 Keywords:               |       Port:
-------------------------+--------------------------------
 This is mostly for reference though I'd love to see a similar feature in
 MacPorts:

 Many if not most Linux distributions have one way or another to keep older
 versions of shared libraries installed if the newer versions introduce ABI
 incompatibilities. Advantages are less and typically smaller upgrades for
 the users, less stress on the build bots and as a result, a more reliable
 upgrade process. That latter claim may need explanation (and may not be
 totally relevant for MacPorts): building binary packages takes time, and
 while those builds are in process users starting an upgrade may find
 themselves in a situation where the new packages aren't yet available. In
 extreme cases that may lead to uninstallation of numerous packages for
 which dependency criteria are no longer met. I've experienced that
 personally with Kubuntu during a KDE version update; I was lucky to have
 taken a ZFS snapshot before starting the update.

 To return closer to home: I was still running a 0.4 port:webp and thought
 I'd update it since it's could be a dependency for QtWebEngine (if that
 package allowed to build against the system webp on OS X). Webp 0.5
 changes the library versioning, so a number of ports broke, including a
 few that are quite (very) expensive to build:

 ```
 --->  Found 11 broken files, matching files to ports
 --->  Found 7 broken ports:
      graphviz @2.38.0 +pangocairo+universal+x11
          /opt/local/bin/dot_builtins
          /opt/local/lib/graphviz/libgvplugin_webp.6.dylib
      ImageMagick @6.9.0-0 +x11
          /opt/local/lib/ImageMagick-6.9.0/modules-Q16/coders/webp.so
      kde4-runtime @4.16.03.80.6 +docs
          /opt/local/lib/kde4/plugins/imageformats/kimg_webp.so
      opencv @3.1.0 +contrib+eigen+python27+qt5+tbb
          /opt/local/lib/libopencv_imgcodecs.3.1.0.dylib
      webkit-gtk @2.4.7 +video
          /opt/local/lib/libwebkitgtk-1.0.0.dylib
      webkit-gtk3 @2.4.7 +video
          /opt/local/lib/libwebkitgtk-3.0.0.dylib
      qt5-kde-devel @5.6.1 +harfbuzz+langselect+qt5kde
 /opt/local/libexec/qt5/Library/Frameworks/QtWebKit.framework/Versions/5/QtWebKit
          /opt/local/share/qt5/plugins/imageformats/libqwebp.dylib
 ```

 The attached PortGroup provides an easy first-approach/PoC solution to
 this issue: it copies the specified runtime libraries from ${prefix} to
 ${destroot} during the post-destroot, if they do not already exist in the
 destroot.

 For instance, in a personal port:webp I used for testing I only needed to
 include the PortGroup and then add the line

 ```
 preserve_libraries      [glob -nocomplain ${prefix}/lib/libwebp*.*.dylib]
 ```

 This simply allows currently installed ports to remain functional using
 their current dependencies and alleviates the need to revbump all
 dependents. They'll just move to using the new dependency version when
 they're rebuilt for other reasons (upgrade, reinstall, ...).
 I'm aware that this kind of practice may lead to runtime weirdness esp.
 with C++ libraries if different versions cannot coexist in a single
 application's runtime image. Easy enough to avoid and apart from that I
 see only one true issue: it won't be trivial to limit the number of old
 versions that will be preserved via a generic mechanism.

-- 
Ticket URL: <https://trac.macports.org/ticket/51689>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list