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 <[email protected]>wrote: > On Fri, Feb 20, 2009 at 11:18 AM, Carol Farlow Lerche <[email protected]> > 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 <[email protected]> wrote: > >> > >> On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso <[email protected]> > 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!) > >> [email protected] > >> 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!) > > [email protected] > > 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!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
