MPlayer @1.0rc4 - hidden dependencies

[janstary (Jan Starý)]

MPlayer has hidden dependencies. At least, it silently picks up audio/opencore-amr and multimedia/ffmpeg.

That is not exactly a surprise, given that the Portfile contains the following misguided comment:

# MPlayer autodetects many support libs.  To prevent undeclared
# dependencies, explicitly disable everything optional first.
# Later, let autodetect do its magic not explicit --enable

Letting autodetect "do its magic" without explicitly --enabling the stuff AND explicitly mentioning it in depends_lib is exactly how undeclared dependencies are created!

For example, I just "port uninstall"ed ffmpeg and opencore-amr

• the installed MPlayer port didn't object, but running mplayer

of course crashed immediately, as mplayer silently depends on those (and most probably many others).

Attached is a diff to the Portfile which --disables the opencore-amr functionality, and adds an explicit dependency on ffmpeg.

I did only this, as I maintain opencore-amr and use ffmpeg, so I stumbled upon this iceberg tip. I leave it to the maintainers of MPlayer to go through all the enable/disable options of MPlayer's ./configure, explicitly enable those that they want, explicitly name them as a library dependency once enabled, and explicitly disabling those they do not want (without having that --disables be later overriden by automagic silent detection).

[janstary (Jan Starý)]

The MPlayer port as built with the diff above now depends on these libs from /opt/local:

/opt/local/lib/libiconv.2.dylib
/opt/local/lib/libncurses.5.dylib
/opt/local/lib/libpng14.14.dylib
/opt/local/lib/libz.1.dylib
/opt/local/lib/libjpeg.8.dylib
/opt/local/lib/libopenjpeg.1.dylib
/opt/local/lib/libbz2.1.0.dylib
/opt/local/lib/liblzo2.2.dylib
/opt/local/lib/libmad.0.dylib
/opt/local/lib/libtheora.0.dylib
/opt/local/lib/libogg.0.dylib
/opt/local/lib/libmp3lame.0.dylib

[ecronin (Eric Cronin)]

First, you probably should be looking at mplayer-devel or mplayer2. The MPlayer port is dead and should just be removed from ports since all it seems to do is cause confusion (it still builds most of the time which is why I'm hesitant to just replaced_by it in case someone really does think a 5 year old completely unsupported by upstream release candidate is better than a slightly less unsupported by upstream port with -devel in its name)

Regarding that comment, the "let autodetect do its magic" part means that explicit --enable-foo or --enable-foo=/opt/local do not do the right thing with (ancient) mplayer's ./configure. To enable a feature you really do need to remove the --disable-foo flag but just let ./configure autodetect that foo is present, instead of adding --enable-foo like you do in normal autoconf'd programs. But the removing of --disable-foo only happens inside variant blocks where the necessary depends are added, e.g.:

variant aa \
    description {Enable animated ASCII art video output} {
    depends_lib-append      port:aalib
    configure.args-delete   --disable-aa
}

This is obviously very brittle, and it looks like some new knobs got added at some point for libraries that didn't exist in macports years ago. ffmpeg is odd since it used to always use a private internal copy and not link against the system version... In fact in comment 2 I don't see ffmpeg listed there. Are you sure it was complaining about ffmpeg and not just opencore-amr?

I'm cc'ing the mplayer-devel and mplayer2 maintainers since they may have similar issues where new autodetected libraries have been added to ./configure that need to be explicitly disabled in the Portfile