[sldev] Viewer Manifest
rdw at lindenlab.com
Tue Feb 27 17:36:33 PST 2007
Christian Westbrook wrote:
> Agreed, Ryan, I appreciate your sharing the news about the new
> installer. Thraxis was good enough to quickly turn out a NSIS script
> that would allow us to ship OpenSL alongside SecondLife without running
> over user settings, or (eventually) things like using different kinds of
> caches, and upgrade independently. It's good to hear you say everyone
> will soon "see the code" -- does this mean the install script itself
> will be GPL'd as well?
Sorry for the delay, the answer is yes. Of course, the OpenSL nsi might
still be better, but that's OK, viewer_manifest.py can be modified to
use that, too.
> Thanks once again,
> Christian Westbrook
> SL: Christian Prior
> christian at openmetaverse.org
> On Feb 24, 2007, at 8:52 PM, Rob Lanphier wrote:
>> Hi Ryan,
>> Thanks for posting this.
>> For everyone else reading this list, I'm hoping you can give your
>> comments on this. One way to make it more likely that Lindens engage
>> with you on your ideas is when you return the favor.
>> Comments inline:
>> On 2/22/07 6:49 PM, Ryan Williams wrote:
>>> This seems like a great time to interject about an installer packaging
>>> script I'm introducing into the next release.
>>> The short story is that building an installer will be one step --
>>> running a Python script. I don't know how much of our installer-making
>>> code has been released, but since the .nsi wasn't, probably "not much".
>> Ooops. That certainly wasn't by design. How does one go about building
>> the installer? I'm assuming it's just a different build target.
>> Has anyone actually tried to build an installer to date?
>>> Either way, with the next source release the installer-making
>>> capabilities should be fully operational.
>> Cool! Let me know which branch you checked your stuff into. Whether or
>> not these changes make it into the very next release depends greatly on
>> which branch it gets into. Certainly, though, "soon" is a correct
>>> I provided documentation for the file here:
>>> I'm certainly interested in discussion about the design and
>>> implementation of the script. Of course, not much discussion can happen
>>> until everyone see the code, but I just wanted to give a heads-up.
>> There seems to be plenty there for discussion, actually.
>> One question that I have (because I know I'll get asked this down the
>> road)...is there existing technology that does this same function that
>> isn't too burdensome to switch to? This is a question for everyone, not
>> just Ryan. I ask this sincerely, because even though I know this
>> problem has been tackled a gazillion times, I also know that the
>> solutions out there are often difficult to extract from the projects
>> that created them.
>> Just to narrow the scope of what would be considered overlapping
>> technology, the idea is that this Python script creates a NSIS installer
>> on Windows, a .dmg on Mac, and a tarball on Linux, right? Since
>> switching installer technologies (at least on Windows and Mac...on
>> Linux, something like Autopackage would be kinda cool) is probably
>> harder than writing a simple python wrapper from scratch, any viable
>> competing technology would need to be able to create an identical
>> installer, and have to have the same simplicity of being just a Python
>> script (or /maybe/ Perl).
>> I wasn't able to find anything. If this is truly unique, one thing that
>> would be very cool to see is someone take the ball and run with it.
>> We're not exactly in the cross-platform installer business, and this
>> seems like a problem that a lot of folks have (see
>> http://www.wxwidgets.org/wiki/index.php/Installers ). If there's
>> someone out there looking to form their own little independent open
>> source project, this might prove to be a great starting point (assuming
>> Ryan hasn't grown too attached to it just yet). I could see this either
>> taking on a life of its own, or perhaps being incorporated in a bigger
>> One piece of feedback regarding the platform magic (e.g. derive from
>> LLManifest and name your class "HP-UXManifest", and that will be
>> selected for use on HP-UX) Platform isn't the only relevant variable in
>> choosing which class to use. For example, down the road, we may wish to
>> have Linux .rpm, Linux .deb, Linux autopackage, etc. Additionally, it
>> may very well be that FreeBSD autopackage and Linux autopackage will
>> share more in common than Linux .rpm and Linux autopackage. So,
>> building out the class tree based exclusively on platform may not be the
>> best thing.
>> Click here to unsubscribe or manage your list subscription:
More information about the SLDev