[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