Multiple ffmpeg versions in ports

Ben Woods woodsb02 at gmail.com
Wed Mar 30 21:28:10 UTC 2016


Hello ports people,

What do you think about having numerous versions of ffmpeg in ports,
similar to lang/python?

There seems to be a common problem with ffmpeg being a fast moving project,
with backward incompatible API/ABI changes between major versions. This
results in regular difficulties building ports which depend on ffmpeg, and
often ports bundle their own version of ffmpeg to avoid incorrect API
difficulties across different operating systems / distros (e.g. HandBrake,
plexhometheater). Bundled libraries should be avoided where possible to
ensure we can provide clarity on where security vulnerabilities exist (of
which there are a few for ffmpeg). [1]

Whilst the ffmpeg team appear to be supporting 2.5.x, 2.6.x, 2.7.x, 2.8.x
and 3.0.x, we probably only need to maintain a port where it is required
for another port to build correctly. To start with I was thinking we should
simply create multimedia/ffmpeg30, move multimedia/ffmpeg to
multimedia/ffmpeg28, and create a dummy multimedia/ffmpeg which depends on
multimedia/ffmpeg30. Any ports which fail to build against
multimedia/ffmpeg30 can instead require multimedia/ffmpeg28, and we could
add a comment next to the dependency reminding the port maintainer to move
to the later version of ffmpeg once it is supported by the package.

This would likely mean we will have a number of versions of ffmpeg in the
ports system over time, but I think it is the reality that different
packages support different versions of the ffmpeg API/ABI, and it would
help keep track of what is vulnerable / outdated rather than hiding it by
bundled ffmpeg versions.

Thoughts? If the idea is supported, I could prepare a phabricator review of
the proposed changes.

[1] https://www.freebsd.org/doc/en/books/porters-handbook/bundled-libs.html

--
From: Benjamin Woods
woodsb02 at gmail.com


More information about the freebsd-ports mailing list