[sldev] Viewer Manifest

[Ryan Williams]

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.

-RYaN

> 
> 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
>> answer.
>>> I provided documentation for the file here:
>>> https://wiki.secondlife.com/wiki/Viewer_Manifest
>>>
>>> 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
>> project.
>>
>> 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.
>>
>> Rob
>>
>>
>> _______________________________________________
>> Click here to unsubscribe or manage your list subscription:
>> /index.html
>