[IAEP] [Sugar-devel] addons.sugarlabs.org is starting to work

[David Farning]

On Fri, Feb 20, 2009 at 11:58 AM, Carol Farlow Lerche <cafl at msbit.com> wrote:
> After looking around I still can't find an automatic way to determine which
> distribution/packaging universe a machine is in.  /etc/*version gives a
> somewhat useful but somewhat lying answer on my Ubuntu platform.  It seems
> an obvious thing to have uname report, but no go.  What have I missed?

This is one of the key issues that distribution package maintainers
run into with Mozilla products.

Talking loosely, Mozilla addons and Mozilla plug-ins are different.
An addon implies that the 'thing' will run inside the walls of what
Mozilla promises to provide.  A plugin needs to interact with bits
outside the walled Mozilla garden.   As an example 'add-blocker' is an
addon, while Flash is a plugin.

Linux distributions must package plugins which are installed via the
distro package management system because then need to be installed as
root.  On the other hand, addons can be grabbed and installed via
addons.mozilla.org because they are installed in the .mozilla dir by
the user.

As we move forward we are going to have to establish what is inside
the walled garden for sugar and what is outside.  But, to be honest,
we are probably 3-6 months away from making those decisions.  It is
going to take a healthy dose of feedback from the distributions about
best practices.

david

> On Thu, Feb 19, 2009 at 9:41 AM, David Farning <dfarning at sugarlabs.org>
> wrote:
>>
>> On Fri, Feb 20, 2009 at 11:18 AM, Carol Farlow Lerche <cafl at msbit.com>
>> wrote:
>> > How does the Mozilla add-on functionality decide if there is a version
>> > or
>> > platform conflict for browser add-ons?  it must be a piece of the
>> > browser
>> > that does this via some interaction with data on the server.  Shouldn't
>> > there be a similar process here?  It is frustrating to download
>> > something
>> > (which can be a problem with bad/intermittent connectivity)  only to
>> > find
>> > that you can't use it.
>>
>> Your browser reports information on the OS and browser version to
>> aslo.  A developer can select which OS and browser version for which
>> they want the activity to work.  My guess is that we will either need
>> to pin a specific version of browse to a os release or else have
>> browse report OS information.
>>
>> BTW, amo, which we call aslo, also handles all of the messaging
>> passing for firefox to update itself daily.  The hooks are there.  We
>> just need to figure out how we want to use them.
>>
>> david
>>
>> > On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd <wadetb at gmail.com> wrote:
>> >>
>> >> On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso <tomeu at sugarlabs.org>
>> >> wrote:
>> >>>
>> >>> A long time ago, when using bundles was decided as necessary, the idea
>> >>> was that there would be something called the "Sugar platform" that
>> >>> would specify every component that an activity author can rely on
>> >>> being available for their activities to use.
>> >>>
>> >>> That would include etoys, csound, pygame, glibc, gtk, and any other
>> >>> components on which the sugar shell may not depend but activities can
>> >>> expect to be there.
>> >>
>> >> I've been part of this discussion a couple of times now and to me it
>> >> seems
>> >> like the original vision is pretty much the right way to go.  As an
>> >> activity
>> >> author I love the simplicity of activity bundles just being ZIP files.
>> >>
>> >>>
>> >>> Everything on which an activity depends and isn't part of the platform
>> >>> should be bundled inside the .xo.
>> >>
>> >> Aside from this point!  Some dependencies are simply too complex to
>> >> bundle, and can introduce conflicts with the host system.
>> >> Aleksey proposed adding a simple "depencencies" line to activity.info.
>> >>  This would be parsed by Sugar in a distribution specific manner by a
>> >> running 'sugar-check-dependencies' script that could be provided by
>> >> each
>> >> distribution.  We would define our own set of dependency names and
>> >> manually
>> >> map them to each distro that we package for.
>> >> For example, a 3D activity which used OpenGL could list "dependencies =
>> >> opengl", and then the various distributions could handle that as needed
>> >> in
>> >> the script.
>> >> If the system does not contain the required dependencies for an
>> >> activity,
>> >> in my opinion Sugar should prompt the user to install the dependencies
>> >> and
>> >> then not launch the activity.
>> >> Best,
>> >> Wade
>> >>
>> >> _______________________________________________
>> >> IAEP -- It's An Education Project (not a laptop project!)
>> >> IAEP at lists.sugarlabs.org
>> >> http://lists.sugarlabs.org/listinfo/iaep
>> >
>> >
>> >
>> > --
>> > "It is difficult to get a man to understand something, when his salary
>> > depends upon his not understanding it." -- Upton Sinclair
>> >
>> > _______________________________________________
>> > IAEP -- It's An Education Project (not a laptop project!)
>> > IAEP at lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/iaep
>> >
>
>
>
> --
> "It is difficult to get a man to understand something, when his salary
> depends upon his not understanding it." -- Upton Sinclair
>