[Libcdio-devel] xine packaging question

[R. Bernstein]

Götz Waschk writes:
 > Hi,
 > 
 > I'm the xine-lib packager for Mandrakelinux. They include their
 > private copies of vcdimager and libcdio, but it's possible to link
 > against the shared versions as well. What would you recommend?
 > 
 > CU, Götz

I suggest the external libraries for these reasons. No one has
committed to maintain the xine libcdio/vcdimager copies, so not
surprisingly they tend to be a bit back-level. In fact, when there was
a security vulnerability found, at least one of the problems didn't
exist in the current libcdio. And if there is a problem between the
external shared library and xine I'll do my best to make sure it is
fixed.

Recall that I wrote the navigable VCD plugin that's now used by
default. If there is a problem in the xine VCD plugin, the first thing
I'll probably want is it tried against the external shared versions. 

And the final reason is that the external versions are COMPLETE which
means for me that when the package was built presumably the regression
tests were run, and they have both documentation and utility test
programs cd-info and vcd-info. There is no provision in the copies to
run regression tests.

So again if someone has a problem I may need vcd-info (or cd-info or
cd-read) output if the debugging that's built inside of the VCD plugin
can't pin-point the problem.

The stated reasons for the copy is for convenience of users who don't
use packaging and don't want to be bothered by downloading multiple
pieces of software to get xine running. For my part, I really don't
care about the convenience of such users and would prefer those people
who feel inconvienced by downloading multiple packages to use the
mandrake packages instead.

Another advantage of the inline copy is that if I break the interface
in libcdio or vcdimager I don't do so because xine has its own
copy. However again if such happens, I will try to fix this
quickly. There was a valid complaint about an incompatible change I
recently made that forces a new vcdimager. It was a mistake on my part
and I will try to do better (i.e. not break compatiblilty) in the
future e.

If you look at xine-devel archives you'll find a bit of discussion
about this. To some extent I feel that I lost the argument so my views
don't seem to be the views of the majority of the xine developers. 

- - -

In xine-vcdnav in CVS I also have a CD-DA plugin which uses
libcdio. Although there are a number of feature that it has that I
like, the default xine doesn't use it.  (If you are familiar with the
xine VCD plugin or the vlc CD-DA plugin it is not hard to imagine what
those features are). For cddb support it uses libcddb.

Comparing the two:

my plugin supports CD-Text and CD-Images. (The default doesn't)

The default CD-DA has musicbrainz support through homegrown code. I
have a patch into libmusicbrainz that should make it possible for a
plugin to use libmusicbrainz. When that patch goes into
libmusicbrainz, the libcdio CD-DA plugin will be extended to include
musicbrainz support.

The default has what some really hacky and custom method of streaming
CD-DA over a network. Here I don't really have a solution. I don't
like custom solutions and don't understand why some other streaming
protocol (RTSP?) can be used.

My understanding is that in vlc one can stream audio CD's and the CD
plugin via libcdio just doesn't have any network streaming code.

- - -

Lastly, on a slightly different but related topic. It should be
possible to make a vcdimager release soon. Unfortunately for personal
reasons I can't devote time to the computer right now.