[MacPorts] #50694: ffmpeg: issues updating to version 3.0

[MacPorts]

#50694: ffmpeg: issues updating to version 3.0
-------------------------------------------------+-------------------------
  Reporter:  devans@…                            |      Owner:  devans@…
      Type:  defect                              |     Status:  new
  Priority:  Normal                              |  Milestone:
 Component:  ports                               |    Version:  2.3.4
Resolution:                                      |   Keywords:
      Port:  baresip cmus ffmpegthumbs FreeRDP   |
  goldendict gpac libdlna libextractor           |
  libquicktime-devel mlt moc OpenSceneGraph      |
  pHash py27-bob-io-video transcode VLC wxsvg    |
  xine-lib xmms2 yorick-av                       |
-------------------------------------------------+-------------------------

Comment (by rjvbertin@…):

 Which VLC port is seeing issues with ffmpeg 3?

 I think that some thought could be given to possible ways in which
 MacPorts could provide multiple ABI-incompatible FFMpeg versions
 concurrently. FFMpeg isn't wholly incomparable to, say, Python, in the
 sense that a distribution system like MacPorts cannot really hope to force
 all "upstreams" to update before "they" feel ready, for the sole reason
 that MacPorts wants the latest and supposedly greatest and nothing else.
 As a distribution system it makes sense to ship the latest version of
 libraries that can support (most) all dependent ports, but that's not to
 say it shouldn't be possible to move on if only a handful of
 pivotal/popular ports remain stuck on an older version of a library.

 On Linux the usual approach would be to provide a package with just the
 runtime binaries, but that isn't feasible when you also need to support
 building a package (port) from source.
 I have been looking at a comparable situation with KDE4 ports that I'd
 like to be co-installable with KF5 versions as long as those aren't proper
 successors that truly replace the older version. For those KDE4 ports I
 have introduced a kf5compat/legacy variant. The principle is simple:
 configure to install to a subprefix (or only the conflicting components if
 the build system is fine-grained enough). Install symlinks to the regular
 locations for the non-conflicting runtime components so that dependent
 software continues to find them, possibly even without a forced rebuild.
 Use of a variant isn't in any way required of course; a hypothetical
 `port:ffmpeg-<currentABIversion>` (`port:ffmpeg-2.4-8`?) could do this by
 default.
 Done right, this would allow
 -1 ports requiring the "legacy" version to keep functioning, and to build
 even with FFMpeg 3 installed (possible requiring patches to their build
 system to ensure the correct install is found; headers and link
 libraries).
 -2 ports that can will use the latest version
 -3 optionally ports from point 1) don't even require a rebuild.

 Would point 1) require building FFMpeg 3 with a comparable install layout,
 so that dependent software cannot include the wrong header file by
 accident?

 NB: for port maintainers for whom a port like FFMpeg is just another
 (central) dependency it could also be *very* appreciable if updates to
 that dependency don't oblige us to rebuild a huge bunch of large ports
 esp. if we depend on those ports for our "real work". That's where point 3
 comes in; my motivation to look at issues with VLC will depend very much
 on the amount of overhead required before I can start doing that.

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