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

[Carol Farlow Lerche]

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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090219/44244e59/attachment-0001.htm