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

[Tomeu Vizoso]

On Thu, Sep 24, 2009 at 12:15, Peter Robinson <pbrobinson at gmail.com> wrote:
> 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".

But we also have activity authors that don't want to go through the
hassle of learning git :/

And even worse, we want people who are not yet able to create
activities from scratch to do simple modifications to existing
activities and redistribute them.

Regards,

Tomeu

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



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning