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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel