[IAEP] Sugar platform overview

[Aleksey Lim]

Hi all

On the threshold of discussing package related issues during next fudcon
I think it demands to be pre-discussed (at least face-to-face fudcon discussion
is restricted in number of participant).

At first, I think just-packaging is not core problem. While packaging sugar for
Gentoo, ALTLinux and TamTam for SoaS(Fedora10) I've realized that there is
a lack of meta-layer of components in sugar. People package sugar for various
distros, they do the same work and at the same time there is no central db for
all sugar/sugar-related components. I do not mean wiki pages, I mean
programmable entities with meta information about components (like
system/sugar dependencies, strings, urls). activities.s.o is called to solve
that lack in case of activities(see below about activities.s.o), but there are
core sugar activities and system-dependencies related problems (installing
valid xulrunner/pygames/...).

My sketchy view on that situation:

       [jhbuild] >>> [meta-db] <<< [non-core activitie]
                         V
                         V
                 [various backends]
                         V
                         V
    [GNU/Linux distros] ... [activities.s.o] ...
            V
            V
    [specific distros like SoaS] ...
            
[jhbuild]
Provides: dependencies, urls to obtain tarballs, etc. in XML format
core-sugar-components development environment

[non-core activitie]
Provides: dependencies, urls to obtain tarballs, etc. in some format
contributions from activities authors

[meta-db]
Provides: meta info for all known sugar components
core part, its a collector of all distro-independent stuff:
dependencies, patches, build-related issues (make/configure arguments)
various content (images, .desktop files), urls to obtain sources, etc.

[various backends]
Provides: proper way to package sugar
templates to generate .rpm .deb .ebuild .autopackage packages
including any distro-specific stuff
in some cases they are light templates - all specific stuff
will be inherited from [meta-db]

[GNU/Linux distros] ... [activities.s.o]
just use generated packages

[specific distros like SoaS]
convenient way to generate specific distros
just point out desired components and run proper backend

I think having central [meta-db] has many benefits:
- collaboration: everybody works in one "trunk"
  not doing the same work while packaging sugar for various distros
  patches/content could be moved from [backends] level to [meta-db] level
  and everybody could benefit from that
- flexibility: we could choose any format for sugar packaging,
  it needs only proper templates 
- central db is the simplest way to discover sugar and adding new components

Note: 
http://sugarlabs.org/go/DeploymentTeam/jhconvert
could be considered as one of the possible prototypes

-- 
Aleksey