[Sugar-devel] [POLL] Non Sugar Platform activities in Activity Library
alsroot at member.fsf.org
Sat Feb 27 09:10:25 EST 2010
On Sat, Feb 27, 2010 at 08:32:53AM -0500, Walter Bender wrote:
> On Sat, Feb 27, 2010 at 3:01 AM, Aleksey Lim <alsroot at member.fsf.org> wrote:
> > On Sat, Feb 27, 2010 at 07:17:54AM +0000, Aleksey Lim wrote:
> >> Hi all,
> >> Before this moment some binary actitieis on ASLO bundle per architeture
> >> blobs since binaries didn't weight much. But it doesn't play in case of
> >> http://www.geogebra.org/ which is Java based application (bundling blobs
> >> per architecture will mean 50M of dependencies and 5M of geogebra itself).
> >> Since Sugar Platform can't grow endlessly, some dependencies can't be
> >> included to SP(here Java). But bundling some of them will be pretty
> >> overkill(Java, Qt etc). At the same time fetching dependencies on
> >> demand(on first launch) could not fit to some deployment models.
> >> So, the question is - how handle such non SP big dependencies in ASLO.
> >> Possible answers:
> >> 1) hmm.. what are you talking about, sugar is pure python environment
> >> and blobs(not python) is evil, ASLO should handle only python
> >> based activities(or activity should bundle all its dependencies)
> >> 2) activities that don't have bundled all dependencies should be
> >> explicitly marked to not mess them w/ fully bundling ones
> >> 3) use complicated model when ASLO makes decision for every downloading,
> >> should dependencies be included or not
> > or less complicated scheme when there will be per architeture bundles,
> > uploader will push pure 0sugar activity and ASLO will cook .xos with
> > all dependencies bundled per architeture.
> >> Please suggest your variants and attach your +/-
> >> --
> >> 2) +1
> >> --
> >> Aleksey
> > --
> > Aleksey
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> Could we have a scheme where by we make a primary bundle and then
> secondary bundles with the arch-dep bits, one per arch. and have a way
> in ASLO to grab from both as needed?
Yup, I meant the same - developer mentions 0sugar deps in activity.info
and upload bundle only with activity itself w/o any deps bundled,
later ASLO will prepare proper set of bundles e.g. per architecture
for binary dependencies.
The issue with this scheme is that we have a mess anyway since .xos are
not fully bundled and contain blobs only for one architecture e.g. if
someone downloaded .xo from ASLO on x86_64 box then copied it to x86
More information about the Sugar-devel