[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xine-devel
Subject:    Re: [xine-devel] Re: [xine-cvs] CVS: xine-lib configure.ac,1.186,1.187
From:       "R. Bernstein" <rocky () panix ! com>
Date:       2003-11-02 13:01:46
[Download RAW message or body]

Since folks in the past felt that I've twisted their words improperly,
I'll reply to comments as exposition that I think addresses the
comments and my and others concerns.

As was mentioned, on xine-devel standpoint there was only discussion
of whether the incomplete and unsharable copies of libcdio and
vcdimager are preferred over the official sharable libraries which
also include diagnostic programs and documentation. 

I have other concerns which I'll also mention below.

The issue for me is not "making things easier" for me but I think
making things better: with more quality, more bug trackable, *and*
easier for everyone.

Some people like myself really don't want multiple copies of the same
thing everywhere. For example, I know many projects include GNU
gettext if it is not installed. However if an acceptable version of
GNU gettext is around and one which is known to work with the project,
as a user I prefer the installed version be used over some project's
unshared copy of that. This is a *user* concern, not a gettext
developer concern. The libcdio and vcdimager libraries use pkg-config
and version numbers and those can be checked to ensure there is a
working version in the same way that say a plugin checks an API number
to make sure it is acceptable.

Some xine developers seem unhappy with this because they believe a
change to the libcdio or libvcdinfo library is going to break
xine-lib. This is only a concern if the version check is for say
libcdio >= 0.64 as it currently is and think it should be rather than
libcdio == 0.64.

Here, I should say that there now needs to be an effort on my part to
only make upward compatible changes. However if there are
*incompatible* change as a xine-lib person I will undertake to make
sure xine-lib is corrected as well.

Now let's look at the flip side. We saw that recently that xine-lib's
ffmpeg got very much out of sync and there was a user who reported a
bug in xine which was traced to this out-of-sync ffmpeg code. The
person reporting the problem also mentioned that they did not have
this problem in mplayer which I'm given to believe has a newer if not
in sync copy of ffmpeg. 

For myself, if there is a bug fix to libcdio or libvcdinfo, I'm not
going to do the double work to change xine-lib (or any other project
that insists on having a copy of the library). One of the many vocal
and insistent people who feel this "has" to be in xine-lib should do
that.

Someone, (not me) added this line now to the CREDITS file in the
top-level xine-lib directory:

[project          version	     mediator
libcdio	          0.64-cvs

There is supposed to be a name at the end. That is currently
missing. This suggests to me again that a user is better off the 
external library rather than the internal one.

Another thing to note from the CREDITS line is that this claims to be
0.64-cvs which predates the officially 0.64 release. A problem with
using any CVS version is that it really doesn't correspond to a fixed
source. What was used was a snapshot and although I like to keep the
source correct at all times, I think it a bad practice to use a
snapshot for a copy of a source. So whatever person volunteered for
this task (and someone in past discussions did), the person should
ensure that the sources are in sync with the last release 0.64. Again,
until that time, I think everyone who has the 0.64 libraries installed
should use that.

And last, concerning the CREDITS file, only libcdio is listed. But
libvcdinfo is used as well. Another line should to be added for
that. Hopefully the mediator can list his/her name and what version
was/is used.

Which leads into the weirdness in the option --with-external-vcdnav
(or --with-internal-vcdnav). VCDNAV is really inappropriate here. As
was noted, there are two libraries: libcdio and libvcdinfo. (Well
actually 3 since there's also libvcd). NEITHER OF THESE HANDLES
NAVIGATION. The navigation part is inside xine lib or the old
xine-vcdx.

Aside from the screwy and incorrect name, the one switch controls
using both libraries. Since it's possible to have libcdio installed
with out libvcdinfo (and libvcd) and since I think it better for the
official libcdio to be used even if vcdimager-cdio isn't, this option
needs to be turned into two. Probably --with-internal/external-libcdio
and --with-internal/external-libvcdinfo.

This has been on my list of things to address and I'll look over
Michael's patch in doing so. 

Finally in passing I received word yesterday from Richard Stallman
that libcdio has been accepted as an official GNU project. As such,
there are a number of small changes that I need to make for that.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
xine-devel mailing list
xine-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel
[prev in list] [next in list] [prev in thread] [next in thread]