[Sugar-devel] [IAEP] [SLOBS] Long-term support for Sugar

[Daniel Drake]

Hi,

2009/9/22 Benjamin M. Schwartz <bmschwar at fas.harvard.edu>:
> This is incompatible with our (or at least my) goal of allowing
> users to throw packages around as atomic objects, without internet access
> and without having to understand anything beyond "my friend has Sugar, so
> it will work".  It is also incompatible with allowing novices to generate
> first-class Activities.

And to throw in a contrasting view: I feel it's unrealistic and
uninteresting for the field.  (even though I would personally be
thrilled to see this)

Before I go further, I want to re-enumerate the items of discussion
and the outstanding problems with the .xo format.


First of all the problems with our current activity packaging:

1. Versioning system sucks, in that it's not obvious which version of
Sugar's activity-exposed APIs each activity is compatible with and you
can't even specify this in the metadata, and hence Sugar can't even
reject activities that we know simply will not work on version x.y.z.

2. Because there is no user-friendly way of installing system-level
libraries, and the bundles itself cannot specify dependencies to be
automatically installed, and even because of a variance of system
libraries available on different sugar distros, we end up with a
common practice of including precompiled libraries within activities.
This is a waste of disk space, makes bundles architecture-specific,
sometimes even makes the bundle specific to a certain set of system
libraries or a specific ABI even within the same architecture, and
includes the usual disadvantages equivalent to "regular software"
using static instead of dynamic linking (if a single bug in a
supporting library is uncovered, multiple bits of software must be
patched, released, distributed, built, and installed).

3. Sometimes, even though the activity does not require any extra
libraries, an activity bundle includes native code -- for example,
someone ports a C/GTK+ app to Sugar - this often involves the C code
being compiled for Fedora/x86 then bundled up with a Python wrapper
inside a .xo bundle. This has some of the same disadvantages as above
- it becomes architecture-specific and ABI-specific.


and, in addition to solutions to the problems described above, people want:

4. The ability to send a Sugar activity to any other Sugar user,
regardless of Sugar version, underlying distribution and version, and
even system architecture

5. The ability to modify activities, revert modifications, and share
modified versions with other Sugar users.

(there are other difficult/controversial things that people want too
-- for example, a guarantee that a shared activity instance of
ActivityX on Sugar-0.86 will continue to be compatible with the shared
activity instance of ActivityX on Sugar-0.94, but I'll try and keep
this discussion limited to the .xo bundle format itself)


and features that we have already that people regard as important:

6. The ability to create a .xo bundle in a simple way from any
platform, and ease of installation onto XO



My own thoughts:

1. Versioning scheme - probably the easiest thing to discuss as it can
be solved easily within the current format. My vote would be to adopt
GNOME's versioning scheme of basing component and application versions
on the version number of the platform. e.g. Write-0.88.1,
Paint-0.86.4, etc.

2. Shipping of binary libraries within bundles - I hate this, even
just because of the duplication. Never mind that it's become a common
practice and is wholly incompatible with Sugar's cross-platform goals.
I think we have 3 options available
 - switch to using distribution package systems which have already
solved these problems. let the distributors take care of this...
 - move to a model where several .xo bundles are generated for each
activity release (e.g. one for Fedora9/x86, one for Fedora11/x86, one
for Fedora11/ppc, one for Ubuntu/x86, etc)
 - ban or discourage this practice, and clearly define which system
libraries are available for activities

My opinion is that distro packaging is the best option, so that
installing the Physics activity can install a system copy of Box2D
from distro repos at the same time. For the Sugar-side implementation,
PackageKit would be the obvious way to go, but as a plan B it would
even be OK (in my opinion) to individually support the common package
managers in modular fashion.

3. Native code on the application-level only: almost exactly the same
set of solutions as (2) and my opinion is the same.

4. Sharing of activities between hugely varying systems: The only real
solution to this that I have seen proposed is for *all* activities to
switch to some kind of cross-platform VM platform (e.g. Java) which
guarantees eternal forward-compat and backwards-compat and will be
able to run on any architecture that we might want Sugar to end up on.
There is no other workable solution that has been discussed --
shipping .xo bundles with native code cannot work if we are to accept
that Sugar runs on multiple architectures, and distro-based packaging
is not realistically going to work on other distros, and also we
aren't even considering the fact that the Sugar platform and the
activity APIs are changing with every release.

I feel that the one available solution is not realistic or sensible,
and I feel this is of very little interest to deployments, who control
and synchronize the systems (all running the same Sugar version on the
same distro on the same architecture) and have good distribution
mechanisms for their users. It's something we'd invest a hell of a lot
of time into fixing, without benefit in the field.

5. Modifying activities: A noble and interesting goal but unlikely to
happen in the field (remember, 6-12 years old users!). I'd like to see
us move in this direction in future, but first I'd like to see us
solidifying the platform and solving the problems/adding missing
features which are actually of importance for deployments.

6. Ease of creation of activity packages
Moving to distro-based packaging will not effect the difficulty of
developing activities, since packaging is something you do after
development, not before.
It will affect packaging and distribution. My suggested model (as
employed all over the open source world) is that the developers would
release source distributions and let distributions do the packaging
and distribution.
Even though a Sugar system with distro-installed packages is crippled
(activities cannot be erased or updated through any realistic means),
we've *already* found some great packagers from Ubuntu, Debian, Fedora
and SUSE who have been distributing activity packages.
In many cases it will be enough just to point out to distros that
you've developed an awesome new activity, but maybe in some cases we
will have to lend a hand to those distributions in order to get things
packaged up. However, there are also a huge amount of people with
packaging expertise who are keen to help. Over the last few years I
have personally dabbled in packaging for Gentoo, Fedora and Ubuntu.
I'm far from an expert in any and have had to ask various questions
every single time, but all of my problems have been quickly solved by
other people more experienced than myself. There is also a huge amount
of documentation available. This is the distributions core business -
they like to package good things, and they are good at doing so.
It is indeed an increase in difficulty of packaging (for the
situations where developers will have a role in packaging, which will
hopefully be less and less), but it also allows us to hand this off to
other people (or at least access a huge amount of expertise), and it
does represent an increase in the quality of our processes and a
solution to some problems.

to summarise my thoughts:
- Some of the outstanding problems are causing headaches for deployments
- Some of the problems are just damn hard to solve
- Some of the missing features are also damn hard to implement and are
of no interest to deployments at this stage
- I think we should focus on what we can do well and making things
easy for deployments before trying to conquer the world

Daniel