Second Life and Portage

Given the latest poll results say there are many Gentoo users browsing this forum, I feel the need to ask:


* What interest, if any, would there be in a secondlife-bin ebuild package using the alpha site?

* If any, is there such an ebuild to keep Second Life's binary up to date without destroying config files?

* If not, would this be possible?

* Finally, what depends would be required for such a package? For multiple architectures? (x86 and amd64, at the very least)



This is in some ways a tangent discussion to whether Second Life should be in apt's package mirrors. But, since ebuilds can use arbitrary download sites, I feel this might be a viable packager for use here.

I love the idea of an ebuild. Anything to make my system more integrated.


Not current, to my knowledge...



Let's see...
Looks like most everything user-specific is in the SecondLife directory. The only exception is lastrun.log. So, you *could* install SL to /opt/secondlife and then write a wrapper script that:

* Creates a symlink from /opt/secondlife/SecondLife to ~/.secondlife, first deleting the current simlink (multiple user support).
* Leave lastrun.log in place, just let it get overwritten. We'll live.
* Executes /opt/secondlife/secondlife

Drop this wrapper into /usr/games/bin/, and you're set.



Hmm, the general deps would be...

darkside@navi ~/sl/bin $ ldd secondlife-bin 
        linux-gate.so.1 =>  (0xffffe000)
        libCg.so => not found
        libCgGL.so => not found
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0xa7ef8000)
        libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xa7e99000)
        libapr-1.so.0 => not found
        libaprutil-1.so.0 => not found
        libboost_regex-gcc-1_32.so.1.32.0 => not found
        libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xa7d91000)
        libcurl.so.3 => /usr/lib/libcurl.so.3 (0xa7d57000)
        libexpat.so.1 => not found
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xa7cce000)
        libjpeg.so => /opt/sun-jdk-1.4.2.10/jre/lib/i686/libjpeg.so (0xa7c95000)
        libkdu_v42R.so => not found
        libogg.so.0 => /usr/lib/libogg.so.0 (0xa7c90000)
        libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0xa7c5f000)
        libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xa7c29000)
        libvorbisenc.so.0 => /usr/lib/libvorbisenc.so.0 (0xa7b2a000)
        libvorbisfile.so.0 => /usr/lib/libvorbisfile.so.0 (0xa7b20000)
        libxmlrpc.so.0 => not found
        libz.so => /lib/libz.so (0xa7b0a000)
        libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 (0xa7a4d000)
        libm.so.6 => /lib/tls/libm.so.6 (0xa7a2a000)
        libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.5/libgcc_s.so.1 (0xa7a20000)
        libc.so.6 => /lib/tls/libc.so.6 (0xa7908000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0xa78f8000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0xa7828000)
        libGL.so.1 => //usr//lib/opengl/nvidia/lib/libGL.so.1 (0xa77a3000)
        libdl.so.2 => /lib/libdl.so.2 (0xa779f000)
        libaa.so.1 => /usr/lib/libaa.so.1 (0xa7780000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xa776d000)
        libidn.so.11 => /usr/lib/libidn.so.11 (0xa773c000)
        libjava.so => /opt/sun-jdk-1.4.2.10/jre/lib/i686/libjava.so (0xa771a000)
        libjvm.so => /opt/sun-jdk-1.4.2.10/jre/lib/i686/client/libjvm.so (0xa72db000)
        /lib/ld-linux.so.2 (0xa7f9e000)
        libGLcore.so.1 => //usr//lib/opengl/nvidia/lib/libGLcore.so.1 (0xa6b19000)
        libnvidia-tls.so.1 => //usr//lib/opengl/nvidia/lib/libnvidia-tls.so.1 (0xa6b17000)
        libncurses.so.5 => /lib/libncurses.so.5 (0xa6ac9000)
        libgpm.so.1 => /lib/libgpm.so.1 (0xa6ac3000)
        libverify.so => /opt/sun-jdk-1.4.2.10/jre/lib/i686/libverify.so (0xa6ab1000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xa6a9b000)

Minus the provided libs from that list...

If no one else wants the job, I could work on making an ebuild for this. It's not inconceivable.

Personally I would rather see an ebuild for Zonax's installer script. SL can update to quickly for portage to keep up, it only takes a snap new client to come out and everyone will be bypassing the packaging systems to get the latest version by hand.

Sounds great, Darkside! I'd be happy to test the ebuild for you and provide feedback.

I'm running amd64 here, and the client always works just fine, apart from its known limitations. The mixture of 64-bit and 32-bit /emul libraries doesn't seem to create any problems.

Excellent.

Gentoo on the portagee tree or as an ebuild would be quite awesome. The one thing that Gentoo can hold over my beloved Slackware is its wonderful emerge command...makes life so easy

Also an option. I doubt, either way, that the gentoo folks would put an unmasked version of this script into the main tree anyway; I was thinking just releasing it as an ebuild and using the overlay directory, in which case keeping up with releases would fall on the ebuild maintainer (er... me, in that scenario).

Basing it on his script does seem like a good idea, though... I'll work on this more when I get my gentoo box back. Or, someone else can do it. Whatever

Yeah an overlay would be perfect, I am just thinking with a script, you can fire off a package and forget about it. This is similar to how SL will work once LL get round to packages, you install a version of the client (any) and the first thing the client does is updsate itself (as the other platform clients do).