[sldev] Viewer Manifest
christian at electricsheepcompany.com
Sat Feb 24 18:08:19 PST 2007
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?
Thanks once again,
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
>> 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-
>> code has been released, but since the .nsi wasn't, probably "not
> Ooops. That certainly wasn't by design. How does one go about
> 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
>> 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
> 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
> 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
> Ryan hasn't grown too attached to it just yet). I could see this
> 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