[sldev] Viewer Manifest

Rob Lanphier robla at lindenlab.com
Sat Feb 24 17:52:34 PST 2007


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070224/fed2bb57/signature-0001.pgp


More information about the SLDev mailing list