[Sugar-devel] Activity packaging

Aleksey Lim alsroot at member.fsf.org
Tue Jul 6 15:56:56 EDT 2010


On Tue, Jul 06, 2010 at 11:51:00AM -0400, Bernie Innocenti wrote:
> On Mon, 2010-07-05 at 16:20 +0200, Tomeu Vizoso wrote:
> 
> > Sorry about the confusion, these questions were about the move from xo
> > bundles to packages :(
> 
> Ah! Communication FAIL! :)
> 
> Ok, I think the requirements for activity bundles could be:
> 
> 1) Support multiple CPU architectures
> 
> 2) Support multiple distros (and different versions of same distro)
> 
> 3) Centralized build cluster (submit one source package, get multiple
>    binary packages)
> 
> 4) Support inter-bundle dependencies
>    (e.g.: GCompris + voices, OOo4Kids + dictionaries)
> 
> 5) Support activity <-> OS dependencies (e.g.: espeak for Speak,
>    squeak for etoys...)
> 
> 6) Work with any programming language (setup.py is python-centric)
> 
> 7) Easy to learn for activity writers without too much distro-hacking
> experience
> 
> 
> These requirements would fit well both rpm and deb, with OpenSUSE Build
> Service or their native build clusters. To obtain (2) and (7), we might
> want to wrap the native packages with a distro-neutral meta-format,
> similar to the current activity.info files.
> 
> I don't know the details yet, but I guess this is pretty much what
> Aleksey is doing with his 0sugar redesign.

Just to mention how it could look like on high level
http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar#How_it_works_at_a_glance

i.e. for activity developer, process should look like pretty straight
forward, everything what he needs is a spec file. Spec file is not like
regular activity.info (some kind of metadata file that is used in
runtime) but a regular spec file like .spec in rpm.

Some examples of real (but for now only built only for 0install)
http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_library
http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Vala_library
and how it will look like for activities
http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_activity

The milestones I'm planing are:

* Having just 0sugar.info spec file (and 0distro build time dependency
  on obs), build native packages on bunch of rpm and deb based distros
  on OBS. I'm planing to have rpm and deb packages for Sucrose, Polyol,
  GC, OOo4Kids built from only 0sugar.info spec files in two weeks

* Having just 0sugar.info and 0sugar tool, distribute  homemade blobs
  (already works) and blobs built on OBS via 0install

* merge all things together and make it useful within sugar
  - move all packaging related stuff from current glucose to some kind
    of packaging core with using 0install as an unified packaging
    "engine", such core could be e.g. a dbus service (but could be a
    library as well) e.g. for now, shell does things like: decides what
    activities to use, from /usr or from ~/Activities, "plain versions
    vs. dotted versions" (sounds a bit amusing). All these tasks will be
    handled within new packaging core
  - switch from bundle_id identification to http urls for activities,
    (at some point it sounds like urls for microformat updates) it could
    be really useful if user on any sugar box could run activity just by
    mentioning its url 

* new UI, how it could look like with new packaging infrastructure

So, Zero Sugar will be useful already in two weeks e.g. it should be possible to attach
Sugar:Platform:Factory repo from obs to have development sucrose on
major rpm/deb distros (http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets)
or install sugarized GC (in form of application or activity) from native packages.

The rest of steps could be implemented in parallel manner.

> I think switching to a native package format is essential:

> currently,
> both the Fedora and Ubuntu teams are spending a lot of time to
> re-packaging just a few activities, resulting in duplicated effort and
> increased "time-to-market" for activities.

just an OBS feature that could be used as is if most of activities will
accessible from obs
http://wiki.sugarlabs.org/go/Activity_Team/Zero_Sugar/Use_Cases#Per_user_Sugar_on_a_stick

-- 
Aleksey


More information about the Sugar-devel mailing list