Installing XINE

[Matthias Saou]

Bill Fink wrote :

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

Alright, I admit : I assume the packages are "well made" :-)

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

Once again the same assumption : The builder _must_ use a clean default
system to build, just like most (if not all) of the original binaries from
the main distributions were built.

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

True, but for the average end user, having a few extras that can come in
handy some day is generally better than not having any. If you're an
"experienced" user, you can rebuild most of my packages trivially,
disabling or enabling options to your liking. Just look at the description.
For xine-lib you have for instance :

--with : rte ext-dvdnav
--without : alsa aalib libfame flac esound arts gnomevfs2 xvid

Which you can use like this :
rpmbuild --rebuild --with foo --without bar yourpackage.src.rpm

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

Most developers don't include distro specific files, the best example would
be recent "freedesktop" desktop files that aren't present in many tarballs.
This is a typical "added value" of good rpm packages.

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

Hmmm, if you use a different distribution or a different version of the
distribution that the package was compiled for, I agree. But if the
packages are meant for the exact distro and version you're running, there
is really no point on recompiling source packages unless you've "messed up"
your system in an incompatible way, or you really want to add/remove a
feature as explained above.

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

This is really weird! Possibly a missing cdparanoia dependency because of 
an ugly way of using it from within xine, thus not getting linked nor
detected as a dependency by rpm... Do you have cdparanoia installed? Could
you eventually try my package again with then without cdparanoia installed?

> 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 would start with trying to define what an "official name" is... when you
have "xine-lib" that becomes "libxine1", you can start wondering. This
naming is clearly not the one used by Red Hat nor Yellow Dog, though it is
by Mandrake and a few others (for rpm, as it is for Debian's debs). For my
packages, I prefer going the Red Hat way, and having "user friendly" names,
which is why I have "xine" and not "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.
[...]

Argh. Well, I'd be grateful if you'd also notify me that I've missed a ppc
package rebuild ;-) If you look carefully, the 0.3.3 package has been
available for i386 for a while. I'll rebuild it for ppc right away.

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

...but please don't forget that I'm always lurking, and that mentioning
eventual mistakes in my packages, releases I forgot to update, suggesting
improvements (patches to my specs ;-)) is all very welcome!

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Raw Hide 20030519 running Linux kernel 2.4.20-13.9
Load : 0.11 0.23 0.27