media-libs/libdvdnav-4.1.2 has been released for over a week now. Emerges without issues after renaming ebuild and tweaking source file URL. This version does not conflict with libdvdread, and can be solution for bug #202433.
libdvdnav-4.1.3 and libdvdread-4.1.3 were released
Created attachment 165596 [details] libdvdread-4.1.3.ebuild
Created attachment 165597 [details] libdvdnav-4.1.3.ebuild Tested with recent trunk of mplayer. Requires libdvdread-4.1.3
(In reply to comment #0) > media-libs/libdvdnav-4.1.2 has been released for over a week now. It's also a fork that breaks API, so we can't just revbump it. yngwin, something else I thought of is that if we put it in the tree, we'd have to make mplayer autodetect it, since we can't dep on it if its going to be hard masked.
also, for the record, I've had libdvd{read,nav} svn ebuilds in my overlay for a while now, we can also use those as a point of reference, though they may need cleaning up. http://overlays.gentoo.org/dev/beandog/browser
There are explicit instructions given for both libdvdread and libdvdnav to not alter API in an incompatible way. I have been running libdvdnav-4.1.2 since a couple of weeks after release and have not had issues with VLC failing to compile or display DVD navigations. These will need to be bumped eventually as mplayer trunk appears to depend on them.
(In reply to comment #6) > There are explicit instructions given for both libdvdread and libdvdnav to not > alter API in an incompatible way. > > I have been running libdvdnav-4.1.2 since a couple of weeks after release and > have not had issues with VLC failing to compile or display DVD navigations. yngwin and I were discussing this earlier on IRC. One thing we have to do is make sure that all apps that depend on libdvdread and libdvdnav still work properly. Also, the libdvdread binary drops some of the util binaries, which may cause some problems. > These will need to be bumped eventually as mplayer trunk appears to depend on > them. Actually, mplayer still ships with internal dvdread, so it's not a problem -- you can use either one.
(In reply to comment #7) > One thing we have to do is make sure that all apps that depend on libdvdread > and libdvdnav still work properly. OK, you can add both ebuilds to ~arch tree, and users will test it soon. In case of incompatibilities it will speed up migrating aps to new version of these libraries.
These versions are now in portage, but hardmasked for the moment, in order to get some testing first.
Any particular reason to prefer configure2 as opposed to autotools? In any case, the original bug has been satisfied and I'm ready to close this unless anyone has objections.
(In reply to comment #10) > Any particular reason to prefer configure2 as opposed to autotools? > > In any case, the original bug has been satisfied and I'm ready to close this > unless anyone has objections. > Autotools is still being hacked together.
