[Bug 1030] Review request: xbmc - Media center

[RPM Fusion Bugzilla]

http://bugzilla.rpmfusion.org/show_bug.cgi?id=1030





--- Comment #110 from Jonathan Dieter <jdieter at gmail.com>  2010-03-02 08:55:58 ---
(In reply to comment #109)
> (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?

Yes.
cximage: http://www.xdp.it/cximage/600/cximage600_full.zip
libcmyth is part of the mvpmc project (and should probably be split out
upstream):
http://sourceforge.net/projects/mvpmc/files/mvpmc/mvpmc-0.3.4/mvpmc-0.3.4.tar.gz/download

Of the two, cximage is the most likely to be used elsewhere.

For the record, cximage hasn't been updated since 2008 and libcmyth since 2007.

> > * libexif (mentioned earlier, already in Fedora)
> 
> This actually isn't *the* libexif, it's totally separate code, just has the
> same name.

Sorry, my mistake.

> > * 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.

I'll take a look at these and see if we can split them out with minimal fuss.

> > * 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.

I don't think so, so I suppose we could just leave that in.

> > * UnrarXLib (can we ditch this and include patches to move to libunrar?)
> 
> I believe upstream has already done so in SVN, I think?

Brilliant, no point in reinventing the wheel for 9.11.

> > * 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.

None of them are currently in Fedora, but they all could be used by other
packages in the future.  If any are currently being used by Fedora packages,
they are bundled as well.

> 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.

True enough.  I've just had a nasty episode with bundled zlib in deltarpm, so
I'd love to make sure we're doing our best to unbundle what we can.  Except for
the legal stuff, I don't consider any of these showstopppers.


-- 
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.