Re: [xine-devel] idea: a xine web installer (was: Re: [xine-user] xine-config)

[Siggi L. <si...@us...>]

On Sun, 20 Apr 2003, Guenter Bartsch wrote:

> most of the ideas mentioned here focus on system-wide installation and
> package systems - which is not what i want to focus on with the
> installer.
[...]

Okay, that's something totally different, then.

[...]
> so what i'm thinking of is providing a single binary installer,
> statically linked, which can be downloaded an run - it should contain
> everything needed to run, all library routines - no external
> dependancies because you never know what software the user has installed
> and what he has not installed (e.g. if the installer wants to use gtk,
> it needs to be statically linked against gtk, if it wants to use
> ncurses, it needs to be statically linked against ncurses ... got the
> idea? :) )

Wuaaah! This would result in a gigantomanic binary, but I got the idea.
The difficult thing won't be the installer but more the statically linked
xine application and library...

[...]
> the last step of the installer is creating a little shell script, e.g.
>
> <user_specified_prefix>/bin/gxine

The location of this script should be configurable (I expect users will
want to install to ~/xine-<versionnumber>, whereas they want the launcher
script as ~/bin/xine).

> which contains something like:
>
> --------------------------------------------------
> #!/bin/sh
>
> XINE_HOME="<user_specified_prefix>"
> LD_LIBRARY_PATH="$XINE_HOME/lib:$LD_LIBRARY_PATH"
> PATH="$XINE_HOME/bin:$PATH"

#Don't forget XINE_PLUGIN_PATH here:
XINE_PLUGIN_PATH="$XINE_HOME/lib/plugins"

> export XINE_HOME LD_LIBRARY_PATH PATH
>
> gxine_bin $*

This should rather be like
exec "$XINE_HOME"/bin/xine_bin "$@"

Using xine instead of gxine will reduce external dependancies a lot,
especially if that's compiled without libcurl support.
Some even simpler interface, like xinimin, may be desirable...
You'll need the complete path, hence the "$XINE_HOME",  you'll want to
prevent forking unnecessarily by using "exec", and you'll want to support
arguments containing spaces ("$@" instead of $*)

> comments?

This won't really work, as your intended target user group won't have X
setup properly, which will cause xine to deliver poor Xshm performance. Or
they will have DMA disabled for their drivers or too slow machines running
with HZ=100 or... (I guess you get the picture: running xine properly
involves some system tweaking on most machines.)

The result would remind me very much of MPlayer, telling me that it
doesn't like my machine, so I should not blame it for playing jumpy video:
a very deterring experience, even worse than not getting it to run in the
first place...

However, an all-in-one binary version of xine would still be useful for
people like you or me who regularly feel the urge to run xine on arbitrary
machines where they are not root.
Moreover, something like this will be required for the Windows port.

Cheers,
	Siggi