[Bug 1030] Review request: xbmc - Media center
RPM Fusion Bugzilla
noreply at rpmfusion.org
Mon Mar 1 23:28:08 CET 2010
http://bugzilla.rpmfusion.org/show_bug.cgi?id=1030
--- Comment #109 from Alex Lancaster <alexl at users.sourceforge.net> 2010-03-01 23:28:07 ---
(In reply to comment #105)
> I would really like to see a number of the libraries in xbmc/lib split out and
> packaged separately (preferably in Fedora).
>
> The ones I'm looking at are:
>
> * cximage (could go into Fedora, I think)
> * libcmyth (could also go into Fedora as it doesn't need to actually be built
> against MythTV, at least as far as I can see).
Are these 2 actual separate projects with URLs?
> * libexif (mentioned earlier, already in Fedora)
This actually isn't *the* libexif, it's totally separate code, just has the
same name.
> * libhdhomerun (already in Fedora)
> * libshout (already in Fedora)
OK, not sure if upstream has facility to use external versions of these 2, or
if it would be easy to patch.
> * libid3tag (already in Fedora, not sure if it includes fixes mentioned in
> xbmc/lib/libid3tag/readme.txt)
I don't think it does include the fixes, I have raised this on:
http://trac.xbmc.org/ticket/8331
> * libxdaap (based on libopendaap, could either package fork or push changes
> back upstream)
Is this used by any other package other than XBMC? if not, I don't see a need.
> * UnrarXLib (can we ditch this and include patches to move to libunrar?)
I believe upstream has already done so in SVN, I think?
> * librtmp (could go into Fedora, I think)
> * libsquish (could go into Fedora unless there are patent problems, not sure
> myself)
> * libupnp (aka Platinum UPnP, could go into Fedora)
These 3 would require new packages, are there other packages that use these
currently, or would likely in the future? Are they *all* necessary for basic
XBMC functionality We should look at what Debian does here.
Some of these, like libid3tag, have been heavily patched by upstream (I have
reported trac ticket) and libid3tag is more or less orphaned as a separate
project anyway.
Ideally, yes it would be good to switch out many of these, and in fact we have
already made a huge effort to do so with other libraries (see the previous
patches by Ralf), but might it be possible to do so an incremental basis? If
the whole package has to wait until every library is packaged, we'll never get
this done, partly because upstream often needs to patch said packages. There
are precedents in Fedora for splitting out stuff post-review.
> I'd also like to see xbmc using system library headers whenever possible rather
> than bundled headers:
>
> * boost
> * libglew
> * libiconv (though /usr/include/iconv.h is totally different from the bundled
> one; don't know how that works!)
> * libportaudio (though we're missing pa_mac_core; unneeded for Linux, perhaps?)
> * sqLite (it seems to be the sqlite3 header and some code having to do with
> datasets; if we can at least ditch the header, that would be great)
> * zlib
I think Ralf's patches addressed most of these. Ralf, can you confirm which
one's the package still uses?
> I would happily review any of these that need to go into either Fedora or RPM
> Fusion, and will also try to help split some of these out.
That would definitely help, thanks! I think the major hassle is going to be
getting XBMC to "see" the external libs.
Although I emphasise the significant work that's already been done on this
package, and I'm concerned if the review hangs on one or 2 very minor external
libs (which may offer only optional functionality) currently being bundled that
are difficult to get XBMC to recognize as "external libs", that the whole
process might stall and people will give up.
Yes, in an ideal world, everything would be split out (and working with
upstream we will do so: upstream SVN is making steps towards that in any case)
but there is a tradeoff between insisting on dotting every i and t to meet the
review guidelines and the amount of volunteer motivation. :-) The only real
showstopper should be the legal one.
--
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the rpmfusion-developers
mailing list