Artwork (Re: [sldev] Packaging the viewer for Linux distributions)

[Rob Lanphier]

Hi all,

Sorry for the delay in jumping into this conversation.  This is on the
agenda for this afternoon, but I wanted to make sure I got something on
the list about this beforehand.

On 10/5/07 2:43 PM, Callum Lerwick wrote:
> Ah, something else on the to do list I've forgotten about. In Fedora,
> we've been encouraging upstream projects to separate (arch-independent)
> game data from source. This is advantageous for us, no only can we issue
> updates to the binaries without everyone having to re-download a large
> amount of game data, but the game data can be a "noarch" package, shared
> across all architectures, reducing storage requirements on our mirrors.
>
> LL already separates the "artwork" from the viewer source, which is most
> of the way there. What makes it much less useful to us is the fact that
> a new artwork tarball comes out with every source release. Could LL
> avoid releasing a new artwork tarball unless it has actually changed? I
> haven't got around to diffing it and seeing how often it actually
> changes, if it is changing, maybe it shouldn't. ;P
>   

The problem is that the artwork releases are an automated process which
is made much faster for us by the fact that we're blindly publishing.

We could also publish some sort of file list difference, but I'm not
sure we have much of an advantage in publishing that.  The easiest way I
can think of is to unpack the two tarballs that we publish the results
of "diff -q" between the two trees to see the file changes.  That's not
something that is especially easier for us, which is why I'm not
inclined to volunteer to do it (since there's plenty of other stuff that
is much easier for Lindens than everyone else that would be just as useful).

That said, I'm pretty eager to see the viewer make it into Linux
distros, so if this is truly on the top of the list for things Linden
Lab should do, then well, maybe we should figure something out.

On 10/5/07 3:43 PM, Dale Glass wrote:
> How about putting the artwork and libraries packages into SVN (or 
> whatever)? That'd allow to tell much more easily when it changes, and 
> updates would be less of a pain.
>   

Maaaaybe.  One big reason for the artwork being the way that it is that
it's difficult to conspicuously mark the copyright associated with each
file.  This is exacerbated by the fact that the artwork isn't in its own
place in our internal tree....it's intermixed with code we GPL (and code
we haven't released yet).  We could publish the code into a separate
tree, but then, in order to build, you'd have to figure out how to
overlay the artwork tree into the source tree.

I'm not sure if svn:externals helps here, since I don't think its
possible to pull two files in the same directory from different places.

We do plan to shuffle our codebase around to remove some of this
silliness, but we're not there yet.  I'm not sure if this particular
problem was a consideration, but I'll bring it up.

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/20071011/82e1125d/signature.pgp