SL as autopackage

I just had the idea why not instead of building packages using the package system of http://www.autopackage.org. What is so nice about autopackage?

Autopackage is made for installing applications as a user instead of systemwide. And as SecondLife also very much is already a userside install I think this could be nice.

Anybody have thoughts about that or experience in buildung autopackages? Maybe we can start with this?

I think we have a great auto installer already...

No experience building autopackages, but as an end user, I've got to say, autopackages are THE WIN! One of my main gripes about linux as compared to windows is how much more difficult it usually is to install software. In windows, all I had to do was find and download and run an exe file. In linux, if it doesn't happen to be in the repositories for my distro, I have to download the source, try and compile it, when it doesn't compile, try and figure out the error message, hope it's just a missing library, install the library, try and compile AGAIN, maybe it even works this time. It's a PitA! But autopackage, it's great! Dl the autopackage, run the script, hit Y a couple times, type the system password (or not, if I don't want the software for all users) and viola!

Hey, thanks guys, nice to know our work is appreciated.

An autopackage of SL has been on my todo list for ages but I don't know if I'll get around to it soon.

Sorry if this is a bit OT.

I have just taken a look at autopackage, having never used it before, and it looks really great!

I just have a question, which may or may not be a problem:

If I install something with autopackage, and it has a dependency which is not already installed, and then autopackage installs that dependency, I might (particularly if I was a newbie) not even know that that dependency had been installed. If I then installed some other package with my distro which also installed the same library or program (which was the dependency for the original autopackaged program) I would have potentially two conflicting versions of the same library/program. Is this a problem? Is there a way that autopackage avoids these problems (like having it's own version of programs that are not on the system path)?

edit:removed bit about trying to autopackage python programs, which I now understand is not possible.

Whether autopackage resolves libraries also available via your distro as a dependency is entirely up to the packagers involved. If it installs a newer copy and then your distro downgrades the library for you then the autopackaged version would break (this is "dll hell". Typically packagers target the libraries that are available by default on everybodies system then bundle the rest privately.



It is possible, it's just awkward if the Python program also contains C extensions and nobody has done the necessary work yet.

Nice to see the autopackage maintainer online here! I think autopackages could be much more interesting in the long run for Linden Labs as conventional packages (as they would have to make many versions to satisfy all). Especially if they like to provide everything the user needs autopackage seems to be the way. Hope you get the time to do this.

Vinci