[Systems] Sweets, Zero Install based Package Management System

[Aleksey Lim]

Hi all!

There is an announce of initial release of Sweets[1], hight level
tools and infrastructure wrapper around Zero Install
(originally, this initiative was named Zero Sugar).

http://wiki.sugarlabs.org/go/Platform_Team/Sweets/1.0/Notes
http://thread.gmane.org/gmane.linux.laptop.olpc.sugar/31940

This is the initial release and has missed some critical points or
bugs. The major purpose for this release is exposing the fact that
basic ideas and core implementations are mature enough to make
Sweets useful and to involve more people in Sweets and Sweets related
project testing and development.

The major purposes of Sweets initiative, were to make entrance
barriers lower (that is especially important for Sugar[2]).
That was done by following methods:

* Add more centralizing (yeah, it sounds like a disadvantage,
  but it see the reset of this text) by using OBS[3] as a central place
  for hosting sources and building binaries.

* Using recipes[4] on top of feeds, feeds will be generated
  automatically on OBS after uploading sources tarball with a release.
  This is a way to simplify releasing worflow, ie, people have a simple
  history-less spec file in human friendly .ini format (Sugar already
  uses files like that for existed distribution method).

* Auto build implementations from sources, e.g., for the call:
    sweets http://sweets.sugarlabs.org/sdk/sugar
  of even shorted
    sweets sdk/sugar
  sweets will auto build all interfaces, that don't have binary
  implementations, from sources and lunch the sweet.

* Local sweets[5] (i.e., packages, not the same as local feeds),
  e.g., to use a directory with sources as a virtual implementation for
  the interface it implements, i.e., without any changing in
  local/remote 0install db.

* Being uploaded to the OBS by the command:
    sweets commit
  the sources will be auto built for all supported (on OBS) distros,
  and after adding previously uploaded releases, the feed files will be
  generated to be accessible from http://sweets.sugarlabs.org/.
  Tarballs will be downloaded from
  http://download.sugarlabs.org/sweets/.

Mostly, it is an experiment. Being entirely based on zinstall-injector
code, Sweets patches it[6] for reasons:

* support virtual feeds to sweet directories,

* closer distro integration like supporting *-devel native packages and
  choosing binary implementations basing on LSB metadata to reuse
  binaries built exactly for targeted distro. The bad thing here is that
  there are bunch of binaries built for the same sources release (but
  the process is automatised on OBS), but the good thing is that people
  all time sure that binaries won't fail due to broken API/API or
  different uild flags.

* more sync approach for Sweets' top level code. It is simplifying the
  code, e.g., PK code in Sweets is:
  http://git.sugarlabs.org/sdk/sweets/blobs/master/zerosugar/local/packagekit.py
  and download related code is:
  http://git.sugarlabs.org/sdk/sweets/blobs/master/zerosugar/local/download.py
  As a result, the main injector process works mostly in sync mode. The
  launch will happen by exec system call. The GUI is working by
  starting injector as a subprocess in slave mode, where all
  interactions between parent and slave process will happen via
  stdin/stdout in JSON notation strings.

This announce is a request to figure out how Sweets implementation's
ideas might be useful for the upstream for better synergy (or, in some
cases, merge).

The another point, is considering possibility if Sugar Labs's OBS instance
might be useful for Zero Install community.
(BCCed to Sugar Labs Infrastructure Team mailing list).

[1] http://wiki.sugarlabs.org/go/Platform_Team/Sweets
[2] http://wiki.sugarlabs.org/go/What_is_Sugar%3F
[3] http://wiki.sugarlabs.org/go/Platform_Team/Open_Build_System
[4] http://wiki.sugarlabs.org/go/Platform_Team/Sweets/Glossary#recipe
[5] http://wiki.sugarlabs.org/go/Platform_Team/Sweets/Glossary#local_sweet
[6] http://git.sugarlabs.org/0sugar/zeroinstall-injector

-- 
Aleksey