[MacPorts] #18286: mlt framework port

[Jean-Michel Pouré]

On Fri, 2009-01-30 at 10:42 -0800, David Evans wrote:
> To upgrade ffmpeg itself to a later revision, all ports that depend
> upon
> it need to be identified and
> evaluated to see if they can live with the new API.  I assume that
> applications that use ffmpeg
> are in the process of switching upstream but the status of that is
> unknown to me at this point.
> 
> It looks to me that we need to start this process and get rid of
> ffmpeg-devel before things get too
> far out of hand.
> 
> Would you like to help?

Debian GNU/Linux has the same problems.

The solution in Debian is to create separate packages for FFmpeg
executables and libraries and develpment headers. FFmpeg is usualy
compiled from a recent SVN snapshot and from releases

Examples:
libavcodec51	3:20080706-0.3 (=recent release or old snapshot)
libavcodec52	3:20090108-0.0 (=svn snapshot)

There is more granularity in packages, which cannot be achieved in
MacPorts.

To achieve this in MacPorts we could:

* Build ffmpeg executables + libraries from recent SVN. For
simplication, we could choose the same svn revisions as Christian
Marillat. The package would be called ffmpeg-52.

* Build old ffmpeg libraries without executables. FFmpeg has these
options during compilation:   --disable-ffmpeg --disable-ffplay
--disable-ffserver. The package would be called ffmpeg-51.

Normally, both versions should be able to live together. Also it would
have the advantage of not breaking existing MacPorts.

I don't have practical knowledged to know if this will work. Maybe a
solution to compile would be to hide FFmpeg incude files somewhere
outside the /opt/local/include path. In each FFmpeg dependant package we
would add /opt/local/include/ffmpeg-51 or /opt/local/include/ffmpeg-52
to the library path before compilation. I have no idea if this can work.

What do you think ? Do you think it is technically possible?

Otherwize, I believe most packages should be able to build against the
newer FFmpeg libraries. But migrating all packages is not a suitable
solution. Some packages will never migrate. Usually this means that
these packages are dead.

Kind regards,
Jean-Michel