[sldev] Packaging the viewer for Linux distributions

Robin Cornelius robin.cornelius at gmail.com
Wed Oct 10 05:39:16 PDT 2007


On 10/10/07, Argent Stonecutter <secret.argent at gmail.com> wrote:
> On 10-Oct-2007, at 03:02, Robin Cornelius wrote:
> > My only concern is that there must be a way of disabling it or
> > perhapses running a custom script etc so if people are following
> > nicholaz patch sets they don't suddenly get updated to a linden
> > original etc.
>
> I would assume the guy making the patch set would put the base rsync
> URL of *his* server in the patched client. :)
>
> In fact, the way to do it would be to have in some XML file in the
> client...
>
> <update-server>http://example.com/thingy/whatzit/osx.xml</update-server>
>
> And that would then return...
>
> <update tag="20071023" path="Contents/
> MacOS">mirror1.example.com::updates/osx/MacOS</update>
> <update tag="20071101" path="Contents/Resources/character"
> type="optional">mirror1.example.com::updates/20071101/character</update>
> ...
>
> Then you could have it return a different mirror on every request.
> >

I really like the sound of this whole approach using rsync etc for
both homebrew distributions and official linden ones. It solves the
linux autoupdating issues (eg not having a updater). It could (in
theory) unify the linux/mac/windows update mechanism therefor easier
to maintain.It reduces overall bandwidth consumption and users time to
get an update and it provides a mechanism to distribute homebrew
viewers in the same way as the official one. Still would need an
installer for windows (and mac?) for first time install but nothing
that complex is needed for an updater.

Another question, is there an easy way to check for homebrew version
updates. I notice from the llstatup.cpp code that it running the
update code based on a reply message to the login attempt. Great for
official linden versions but for homebrew versions where we might have
more releases than the lindens do with various patches being tested
often etc, we need  a way to say there is an update available. I
presume I would have to add a hack in there to do some kind of http
look up against a php page on my server that reported if an update was
available or not (or at least what the current version on the server
is) and from that kick the update_app() code as required? any thoughts
on this?

Robin


More information about the SLDev mailing list