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

[janstary (Jan Starý)]

Replying to ecronin@…:

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)

The only reason why I am using MPlayer @1.0rc4, out of those three, is that "port install mplayer" is the first that comes to mind. I believe it's in the names of the ports, which seem to suggest (to me anyway):

mplayer  = the regular stuff
mplayer2 = new version, if you are adventurous
mplayer-devel = bleeding edge, if you are more adventurous

If the ports were named "mplayer1", "mplayer", "mplayer1-devel" (instead of, respectively, "mplayer", "mplayer2", "mplayer-devel"), I believe people would be just using MPlayer2, because that would be what the obvious "port install mplayer" would do.

Anyway, now that know of Mplayer2 (thank you), I will switch to that -- and take my bitching there.

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

Ugh, another reason to kill mplayer (1.0).

ffmpeg is odd since it used to always use a private internal copy and not link against the system version...

Another reason.

I read Mplayer2 kicks the internal ffmpeg out, makes it a winner.

Thanks again

[ecronin (Eric Cronin)]

Replying to hans@…:

The only reason why I am using MPlayer @1.0rc4, out of those three, is that "port install mplayer" is the first that comes to mind. I believe it's in the names of the ports, which seem to suggest (to me anyway):

mplayer  = the regular stuff
mplayer2 = new version, if you are adventurous
mplayer-devel = bleeding edge, if you are more adventurous

The issue with mplayer is that the only thing supported by upstream is the bleeding edge. They don't roll releases, they only put up patches to the most serious security issues, they tell you to go away unless you're running a SVN build from within the last few hours... Our mplayer-devel port tries to strike a middle ground by picking a specific not too old svn revision, testing it out, and leaving it alone for a few months unless there's an issue that needs dealing with. mplayer2 is a fairly new fork/rewrite and is the least mature of the three, I have no idea if it or mplayer-devel is preferable for the average user. Unless they added it back recently, mplayer2 dropped mencoder entirely which makes it less useful to me.

If the ports were named "mplayer1", "mplayer", "mplayer1-devel" (instead of, respectively, "mplayer", "mplayer2", "mplayer-devel"), I believe people would be just using MPlayer2, because that would be what the obvious "port install mplayer" would do.

Yes, there are many things unfortunate about the port being named MPlayer (capitalization included), but renaming ports once they exist is complicated. mplayer2 made things worse as it is a fork+rewrite of mplayer and not a new version of mplayer, both mplayer-devel and mplayer2 are under active development.

Going to close with the assumption r90448 took care of this.

[janstary (Jan Starý)]

No, it doesn't take care of it. It takes care of the one instance: mplayer built with --disable-libopencore_amrnb --disable-libopencore_amrwb no longer depends (as in 'otool -L') on the opencore* libs, but it has (possibly) more of these hidden dependencies.

The maintainers need to go through the available options, and make sure that every library that the resulting mplayer depends on is indeed mentioned as the port's dependency.

My patch only does that for the opencore* libraries.

[ecronin (Eric Cronin)]

./configure --help |grep -- --disable|wc -l
     119

Some of those try to draw in libraries, some of them don't, any of them may cause weird issues blindly disabling that would need to be tested. MPlayer is nomaintainer. Patches welcome.

Until someone provides a patch or takes maintainership wontfixing. mplayer-devel should probably get its own ticket for this since it's maintained, I have no idea if mplayer2 is as "helpful" in automatically enabling every library it can find, that would be a third ticket if it is (the Portfile for mplayer2 doesn't resemble MPlayer or mplayer-devel)

[janstary (Jan Starý)]

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

I believe a comment like this should be present in the Portfile to explain it to the innocent Portifle reader.

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?

Yes you, are right. It does not depend on ffmpeg (as installed by the ffmpeg port). It links (statically, probably) against its own copy of ffmpeg.

[ecronin (Eric Cronin)]

Replying to hans@…:

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

I believe a comment like this should be present in the Portfile to explain it to the innocent Portifle reader.

r90625 for MPlayer and mplayer-devel.