On Fri, 2006-11-24 at 19:52 +0100, Axel Thimm wrote:
And please note that the target group we're talking about are
simple
users (even though they may be very skillful programmers), not some
package monkeys that will create rpms and debs for all systems
required or that even care about DSO, tarballing their runtime
enviroment and scripting launchers and so on (just quoting some
solutions offered in this thread).
The Second Life client is a proprietary app distributed in binary form,
that's expected to run on any distribution. It commonly run on Fedora,
Ubuntu, SuSe and Debian. Its the *cough* Gentoo users that seem to have
problems...
Its a fairly complex app with tons of library deps. So many that I'm not
going to paste an ldd dump here. It is started with a wrapper script
that sets LD_LIRBARY_PATH, and ships with a selection of shared libs
known to be problematic:
libapr-1.so.0
libaprutil-1.so.0
libcrypto.so.0.9.7
libcurl.so.3
libdb-4.2.so
libexpat.so.1
libfmod-3.75.so
libkdu_v42R.so
libogg.so.0
libssl.so.0.9.7
libstdc++.so.6
libvorbisenc.so.0
libvorbisfile.so.0
libvorbis.so.0
libxmlrpc.so.0
Shipping a dynamically compiled app in a single tarball capable of
running on multiple distributions is quite possible. It works for Linden
Lab, and Google Earth is shipped in a similar manner.
Your only argument seems to be that these skillful programmers, that
presumably have advanced math degrees if they're programming scientific
number crunching apps, and can figure out how to statically compile
their app, are too retarded to write a trivial one line wrapper script,
run ldd on their app, and tar up their app with the libs it needs.