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

[Kevin Kofler]

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?

        Kevin Kofler