Installing XINE

[Bill Fink]

Hi Matthias,

On Wed May 21 2003, Matthias Saou wrote:

> Bill Fink wrote :
> 
> > It's even easier than that to build xine from source:
> > 
> > 	rpm -ta xine-lib-1-beta12.tar.gz
> > 	rpm -U /usr/src/rpm/RPMS/ppc/libxine1-1_beta12-1.ppc.rpm
> > 	/usr/src/rpm/RPMS/ppc/libxine1-devel-1_beta12-1.ppc.rpm rpm -ta
> > 	xine-ui-0.9.21.tar.gz rpm -U
> > 	/usr/src/rpm/RPMS/ppc/xine-ui-0.9.21-1.ppc.rpm
> 
> Alright, this is by far the best "installing from sources" method, but
> still. I'll be quite partial on this, but I just want to mention some
> reasons for installing from binary packages :

In general I agree that under most circumstances using a binary RPM
if it's available is the easiest and preferred method, and that is the
approach I have previously recommended for installing xine.  The above
procedure for building xine from source was given to indicate how easy
it is to build xine, and for those users who either need to or want to
build xine from source.

> - You keep your system cleaner, easier to manage

Since the scheme I described uses RPMs, your system is still as clean
and easy to manage.

> - Upgrading to the next version is much easier, no old libs in the way

Again, using "rpm -U" accomplishes the same thing.

> - Changed configuration files are automatically saved (n/a with xine)

Still using RPMs.  Of course this point depends on whoever wrote the
SPEC file for the RPM.

> - You usually get something "known to work"

Presumably known to work on the system of the binary RPM builder, and
thus hopefully (but not necessarily) will also work fine on the user's
system.

> - You usually get support for useful extra features (faad2, xvid, flac...)

This has a flip side.  Even if you have no interest in these extra
features, you're forced to install all the extra RPMs to satisfy all
the dependencies.

> - You usually get better system integration (init script, menu entry)

If the package developer includes a SPEC file so that you can do
the "rpm -ta", then they have probably taken care of this.  In any
event this depends again on whoever created the SPEC file.

> - You usually get apt/yum support for lightening quick installs! ;-)

That is definitely nice.  I was glad to see that freshrpms has yum
support.

> And there are many others IMHO.

And there are some reasons for having to build from a source RPM
rather than using a binary RPM, foremost among them being if your
system has an incompatible environment from that of the binary RPM
builder, such as a different glibc or XFree86 (for the xine case).

I did try out the freshrpms binary xine RPMs and they worked quite
well on all my test streams, but in the end I decided not to use
them.  First, there was a minor problem with using the CDDA plugin,
which complained about not being able to find the libcdda shared
library (which I don't get with the xine RPMs I built myself).
However, this was just a minor annoyance since the CDDA plugin
still worked fine to play a CD despite spitting out this error
message.

The more serious issue is that the freshrpms xine RPMs don't use
the "official" package names (as defined by the xine provided SPEC
files).  I first got bit by this when I tried using the freshrpms
xine-skins RPM with my personally built xine RPMs, and couldn't use
it because it has a dependency on xine rather than xine-ui.

I then replaced my personally built xine RPMs with the ones from
freshrpms, and as I mentioned earlier, the xine/xine-lib combo
worked very well (with just the minor CDDA plugin glitch).  But
then I decided to try out the freshrpms gxine RPM.  I quickly
discovered that gxine always immediately segfaults on my system
when trying to play any media stream.

Since this is a known problem with the 0.3.2 version of gxine (which
is what freshrpms provides), I decided to upgrade to the 0.3.3 version.
This is another obvious case where you need to build from source, i.e.
there is no binary RPM available.  So using the same basic procedure
as for xine-ui/xine-lib, namely:

	rpm -ta gxine-0.3.3.tar.gz
	rpm -U /usr/src/rpm/RPMS/ppc/gxine-0.3.3-1.ppc.rpm

During the process, I discovered I had to do a "yum install glib2-devel"
and a "yum install gtk2-devel" first, since I didn't already have them
on the system.  To install the gxine RPM, I had to replace the freshrpms
xine RPMS with my personally built xine RPMS, since the gxine RPM I
just built has a dependency on libxine1 rather than xine-lib.  I could
have hacked the SPEC file, but I'd rather not do that if at all possible.

The new 0.3.3 version of gxine works fine (after changing the
misc.memcpy_method entry in ~/.gxine/config to glibc to fix a
serious audio/video issue), although I still personally prefer
the xine-ui GUI.  My main interest in gxine is its mozilla plugin,
which seems to work fine with embedded web media streams (but not
too well with actual links to media streams, for which it's better
to first download the entire stream to disk and then play it with
xine or gxine).

In summary, for most users (including myself) and most circumstances,
using binary RPMs is the easiest and preferred method, but there are
some cases where building from a source RPM or source tar.gz file is
either necessary or desirable.

						-Bill