[sugar] packaging Sugar

[Jani Monoses]

Hello all,

I have started making Ubuntu Feisty packages for sugar and its dependencies
and came up with a few questions in the process.

1) Versioning : there's a VERSION and a RELEASE number in the build-snapshot
scripts of artwork and sugar. I am not sure what RELEASE stands for, I thought
I'd simply use VERSION for the debian package.

2) Copyrights and authorship:
There are Red Hat, Inc. and OLPC copyright statements throughout the code but not
in all files. (For instance hippo-canvas has none, so I just used Red Hat)
The AUTHORS files are empty so I added Marco for the time being as he commited the most
in sugar and the artwork.

3) Artwork:
Would the tarball be not better named sugar-artwork instead of olpc-artwork? I think
it would be more suggestive as a package name. Only needs a change in configure.in and
build-snapshot.sh AFAICS. I filed a ticket to make it install the gtk engine where
the other engines are: http://dev.laptop.org/ticket/1194

4) Sugar:
I see the dist tarball installs both pyc and pyo files and they seem to be the same.

In jhbuild sugar depends on libabiword even though only two activities need it
(write and develop) and not the framework itself. This does not affect packaging though.

I thought of making a sugar package (the framework) and a sugar-emulator one (probably
just that script). As for the existing core activities I am not sure which way would be best.
-make one sugar-base-activities package with the existing ones that have no large deps
-package the same ones along with the sugar framework itself thus avoiding API skews.
-one deb per activity (overkill IMHO)

Are there foreseeable changes in the API which could make a release of current sugar with Ubuntu
undesirable, for instance an incompatible change that would make activities written two months from
not be unusable on feisty. Packages would still have the value of getting started quick with Sugar
development with no jhbuild though.

I'll need to figure out how to use the system avahi and network manager as there may be some overlap
in what dbus services sugar provides in this area.

Right now hippocanvas is packaged and in the archives, and the system matchbox applied two fixes
from svn so it works well with Sugar. As abiword 2.5 is unstable I am not sure I'll package it for
feisty especially since conflicts with the existing 2.4 install may arise, and I'd rather leave this
to the original Debian maintainers of Abiword.

thanks
Jani