[Clipart] Update Packages

[Bryce Harrington]

On Tue, Apr 19, 2005 at 01:40:48PM -0400, Nathan Eady wrote:
> >>I have thought about this, but this may be the first time it has been
> >>brought up on the list.  The main problem I see is with the logistics
> >>of how the user would merge the updates into the previously-downloaded
> >>release.
> 
> Of course, if there were an unpackaging tool familiar with the
> particulars of the package format, it could handle that, but I
> think for the moment we have to assume such a thing is future;
> right now, I think anything we release needs to be usable as
> it stands.  So, how would the user go about merging the updates?

>From a larger viewpoint, you could also consider the case of
non-openclipart clipart being added.  That might suggest installing each
update to a separate tree.  E.g.:

 /usr/share/clipart/openclipart-0.12/
                    openclipart-0.13-update/
		    openclipart-0.14-update/
		    OOo-clipart-1.00/
		    bobs-clipart-pack-0.1/
		    etc.

Then have the "merging" be performed by the userland tool, or through
some intermediary service provisioning tool like is done for fonts.


The above idea sort of defines the problem in terms of package
management.  Make each update a separate package, then it can be
installed and managed just like any other package.


You could also redefine the problem to be one of file sharing, and then
look at what sorts of file sharing technologies it'd fit into.  For
instance, it would be slick if instead of installing a huge clipart
package, if I could simply run a program that sets up and manages a
clipart index with thumbnails, that my drawing tools could use, and then
when I select a file, it transparently downloads it from a remote mirror
somewhere and caches it on my system.  This might be more technically
complex, and is less fail-safe than the package approach, but has an
advantage for the user in that their collection would always be up to
date.  In theory, this same system could be used for contributing images
back into the library.


Another way to redefine the problem is as a version control system.
Instead of packages, we'd have an open repository that contains the
files.  The user would run a command to check out a copy of the repo,
and periodically run an update command to resync it with the master.


There's pros and cons to each of these approaches, and a lot of things
to consider:

   * Will it encourage and enable increased contributions by the users?

   * Would it be platform limited?

   * Would it be too time consuming to implement?  Or is there an app
     that already does it that we could more or less reuse?

   * How well would it scale?  Could it handle 10,000 users?

   * What administrative duties will it have?

Bryce