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

[Peter Robinson]

Hi,

Thank you Daniel for documenting all of that. I agree with your
points. There's a lot of "it would be cool if it does this" but in
most cases of deployments it just doesn't seem to be an issue.

> 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.

I have a possible solution to this which would allow automatic
creation of rpms. I need to get time to sit down and see if this is
going to work which I don't think I'll get until late Oct at the
earliest but it should get us to a point where a Activity is tagged in
git and a while later a rpm in available in a repository. I'll post
more once I get the time to test my theory. If its proven it will
basically remove the arguement of "rpms are too hard for the
developers to make and they don't have the time to do so".

> 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

Agreed.

Regards,
Peter