mplayer + dvdnav + dvdread svn ebuilds

I updated the mplayer and dvdnav ebuilds in my small overlay, and added one for dvdread now, which has been split into a separate package.  I haven’t had time in the past while to keep an eye on what’s been going on, but I do know that the heavy flurry of development has stopped, and that the installer works better.  Plus, the software works fine for me. 🙂

My overlay isn’t in layman right now, so if you want to check it out, here’s the skinny:

svn co http://overlays.gentoo.org/svn/dev/beandog/

Have fun and lemme know if there’s any problems.

4 comments on “mplayer + dvdnav + dvdread svn ebuilds

  1. iwbcman

    I just tried out your overlay and it was really nice having mplayer being able to navigate DVD menus on some of the commercial DVD’s I have which last year kept forcing me to use Windows to even be able to play.

    Unfortunately no other program which needs libdvdread or libdvdnav will work with these versions. So I was in a dilemna -either have a wonderfully working mplayer with functional DVD navigation and no other programs which need libdvdread or libdvdnav, or have those programs which need libdvdread or libdvdnav and no mplayer with DVD navigation.

    I decided to try to get the best of both worlds. I mimicked step for the step the instructions contained in the ebuilds and manually installed libdvdread, libdvdnav and mplayer in /usr/local. I finally got it all working but it cost me hours of work.

    Just a few foot notes on the steps taken and a request.

    In order to install this functional version of libdvdnav you must *only* have its respective version of libdvdread installed. Any other version of libdvdread installed anywhere on the system, regardless of how many ./configure options you pass, or how you manipulate the path will muck up libdvdnav and later prevent mplayer from working.

    The ./configure2 scripts are an ABOMINATION. Libdvdnav’s configure2 script is so fragile it will fail to build liddvdnavmini if you look at it the wrong way, on sundays, when it is raining. ./autogen.sh to the rescue- I took the ./configure2 options from the ebuild and after deleting shlibdir and extra-cflags I managed to get ./autogen.sh to actucally correctly configure the make.

    I had to put mplayer in package.provided and if portage asks me to rebuild or update mplayer again I am going to scream. ./configing mplayer is not for the meek or timid souls. Unlike almost all other programs, when emerge configures a program it spews out the used ./configure options to the screen, mplayer is not so kind. So I spent at 30 minutes deciphering the || ! –disable-funkiness logic in the ebuild to actually form the ./configure options to pass to mplayer. Only after having removed portage versions of libdvdread and libdvdnav (and all the apps which depend on them) was I able to actually get mplayer working with the /usr/local manually compiled versions.

    Now to my question: How hard would it be to hack mplayer into simply using these versions of libdvdread and libdvdnav ?. Given that no other program on earth can use these versions and that the libdvdnav/libdvdread built into the mplayer trunk do not work(ie. do not produce a mplayer which can actually navigate DVD menus), it would be so cool if one could just emerge a version of mplayer which made use of these versions of libdvdread/libdvdnav with not installed pkgconfig files and no ebuilds for them.

    Note I am not asking how much work would be involved to get mplayer to actually integrate this work into mplayer itself so that I didn’t have to execute the program with mplayer dvdnav://. Or to get the DVD submenu in the mplayer menu to actually do anything usefull. I know that would be a lot of work.

    But how hard would it be in an ebuild to just svn mplayer and libdvdnav and libdvdread, stripping out mplayers internal(?°*!) versions, doing away with dvdnav and livdvdread directories upon installation, (perhaps renaming dvdread-config and dvdnav-config so that they do not conflict with other versions and eliminating their pkgconfig files so that one could just install this version of mplayer and have no conflicts with other programs ?

    I think I just answered my own question-god is that complex-so many hacks, so many steps, redoing all the ./configure2 logic etc. But my question remains – would you be interested in such work ?, it would be a great service to Gentoo users and maybe the upstream mplayers devs could even make use of your work.

    I have only succeeded in modifying a configure script once in my life by blocking out a code section-my coding skills are not even in the ballpark of what would be necessary for me to tack such-otherwise I would offer to do such. Maybe I should send this request to Diego, he comes off as a kind of autotools god.

    Reply
  2. Sean C. McCord

    The easiest, I think, would be to have the ebuild grab the Mplayer-specific libdvdnav and libdvdread libraries, unpack them all into the working directory, build them first, then build mplayer, staticly-linking those libraries, and continue the rest of the install as usual. I’ve noticed a few other ebuilds do this type of thing.

    Is this viable, or are things other than the simple libraries required from the dvdnav and dvdread “packages”?

    Reply
  3. Steve

    Sean,

    Well, its a pretty moot point now .. mplayer now uses the forked version directly. Very soon the ebuilds will start using that as well.

    Reply
  4. Ben Dailey

    Steve,

    Thanks for great blogs on this topic will you be posting an update when the ebuilds begin reflecting the upstream changes?

    Again Thanks,
    Ben

    Reply

Leave a Reply to iwbcmanCancel reply