[Sugar-devel] Activity packaging

[Aleksey Lim]

On Tue, Jul 06, 2010 at 05:59:04PM -0400, Bernie Innocenti wrote:
> On Tue, 2010-07-06 at 19:56 +0000, Aleksey Lim wrote:
> 
> > 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
> 
> Will it also remove the need to ship "fat bundles", as we do now?
> I mean, will it produce separate packages for each architecture/os or
> just one large package with many binaries in it?
> 
> I tend to prefer the first way, like rpm and deb do.

There is no any bundles in core design i.e. if you are talking about
"fat bundles" we are talking about distribution method, in my mind
such distribution methods could be:

* via distro repos on obs(or other build farm), users attach these repos

* via 0install, user just type "sugar-activity/0lauch http-url" to
  start activity or any software

* for sneakernet, 0sugar tool could generate bundles like "./setup.py
  dist_xo" does, imho there is not huge need in having smart/fat bundles
  like I tried to to with "0installed" bundles; but anyway later
  practice will make it more clear

> >   - 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
> 
> Wouldn't PackageKit be a perfect match for this?

Firstly, 0install already can install native packages via PackageKit and
secondly (keeping in mind your reply to Benjamin), talking about *only*
native packages we loose one simple and core-for-sugar thing, any sugar user
should be, at the end, a doer. For example, if we have TuxPaint activity
and many doers are experimenting (change C code and compile) with it,
what can do a person, who decides to try all these TuxPaint activities,
having native packages as only distribution method? ask all doers use the
same repo (sounds useless); attach repos per doer (conflicts); handle all
issues by himself (not useful as well). With having 0install (which is
already exists and works) as engine, we handle these issues automatically.

Using 0install doesn't mean that everything is ok with 0install from
sugar pov, e.g. one of core sugar workflows when user need only place
activity to ~/Activities to make it useful is absent in 0install (it
designed as regular packaging system e.g. there is no need in changing
some software in /usr/lib). So, 0install is required later hacking but
it effectively solve last of packaging issues - how to *launch*(not
install) arbitrary activity in heterogeneous environment.

> > 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.
> 
> It's an amazing piece of work, Aleksey!!
> 
> Considering that you're tackling on the hardest problem in the Sugar
> universe, I'm very impressed by the progress you've made in such a short
> amount of time.

Well, not so short amount of time, my first commit to jhconvert (my
first experience in meta packaging) was Fri Dec 05 01:29:55 +0000 2008

-- 
Aleksey