[MacPorts] #33489: MPlayer @1.0rc4 - hidden dependencies
MacPorts
noreply at macports.org
Tue Mar 6 02:27:26 PST 2012
#33489: MPlayer @1.0rc4 - hidden dependencies
---------------------------+------------------------------------------------
Reporter: hans@… | Owner: macports-tickets@…
Type: defect | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 2.0.4
Keywords: | Port: MPlayer
---------------------------+------------------------------------------------
Comment(by hans@…):
Replying to [comment:2 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
--
Ticket URL: <https://trac.macports.org/ticket/33489#comment:3>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list