Moving xine-lib and dependent apps to RPM Fusion Free for F17?

[Michael J Gruber]

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