Kevin Kofler venit, vidit, dixit 05.01.2012 20:56: > Hi, > > the current xine-lib maintainer speaking. :-) > > The Xine project: > http://www.xine-project.org/home > has recently released a new major version, version 1.2.0. > > Unfortunately, among the list of changes: > http://sourceforge.net/projects/xine/files/xine-lib/1.2.0/README.txt.asc/view > there are these new "features": > * Use libavutil-provided implementations for CRC, SHA1 and BASE64 algorithms, > this makes use of libavutil even outside the FFmpeg decoding plugin, > but avoid duplication of algorithms between different plugins. > * Use av_mallocz() when xine_xmalloc_aligned() wouldn't be needed. > * FFmpeg is now required as an external dependency; if you want to build > xine-lib from source, please download a copy of FFmpeg from their SVN > server. > which basically mean that xine-lib now has a global, non-optional dependency > on FFmpeg's libavutil library. > > So there are 4 possible ways forward: > (a) Stick with 1.1.x forever. I don't think that's a good idea in the long > run, upstream won't be providing security fixes for the old branch forever. > (b) Package libavutil (and only libavutil) from FFmpeg in Fedora. (I don't > think libavutil, as opposed to libavcodec, is actually patent-encumbered, > though that'd also have to be checked.) The issue there is that FFmpeg > upstream obviously doesn't support this. It would need some more black > packaging magic of the kind already done in xine-lib, and more legal > auditing. I don't think I want to investigate going down that road. > (c) Bundle parts or all of libavutil with xine-lib. Yuck!!! > (d) Move the whole thing (back) to RPM Fusion (where it originally was, before > we started needing xine-lib for Amarok and Phonon, which both no longer > use it). It would go to the Free section, of course. > My proposal is to go with (d). > > The following packages currently depend on xine-lib: > * gxine > * (k9copy – already in RPM Fusion, not affected) > * kaffeine (my package, the reason why I maintain xine-lib in the first place) > * oxine > * xine-plugin > * xine-ui > These packages would have to move to RPM Fusion along with xine-lib. > > In Kaffeine's case, upstream is switching from xine-lib to MPlayer in their git > repository, so it will likely have to move to RPM Fusion sooner or later > anyway. This means the affected packages are basically *xine*. > > So my plan is to retire (for my packages, resp. have the respective maintainer > retire) the listed packages in Fedora for Fedora ≥ 17 and get (or have the > respective maintainer get) them into RPM Fusion Free instead. (I'd take care > of xine-lib and kaffeine myself, I hope the maintainers of the other packages > will take care of them.) > > Comments? Objections? [xine-ui maintainer speaking] No objection, d is clearly the best option. I don't know anything about rpmfusion packaging and infrastructure, so I'd be happy if someone picks up xine-ui there. In fact, xine-ui gets most xine related abrt reports, it seems, and I always found it difficult to decide whether those are really xine-ui or xine-lib issues. So, xine-ui would best be put into the xine-lib maintainer's hands anyways ;) Michael -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
