Activity Team/Packaging Ideas
Purpose
Installing activities on every sugarized GNU/Linux distribution(not only XO) just by clicking on icon in addons.sugarlabs.org.
Problems to solve
- install proper dependencies
- install activity itself
- blobs in activities
- should we build non-pure-python activities while installing or use binary packages
- and in general, how treat variety of platforms: x86, x86_64 and future ARM, MIPS
- ...
Proposal schemas
...
Distro teams should take care about it
...
Pro
- thats enough for XO alsroot 12:36, 13 January 2009 (UTC)
- ...
Contra
- thats not enough for rest of distros
each distro team has to work out the same work
like inventing theirs own mechanisms to treat activities dependencies etc. alsroot 12:36, 13 January 2009 (UTC) - ...
Invent-own/reuse-exists packaging format
...
Pro
- ...
Contra
- ...
Sugar is like a Firefox and activities are like addons
...
Pro
- ...
Contra
- what about variety of possible dependencies, should we pre-install them all ? alsroot 12:36, 13 January 2009 (UTC)
- ...
Use distro-specific activities installer
That is some kind of #Invent-own/reuse-exists packaging format packaging format, but it move central of gravity to distro-specific installer from packaged activity itself
Pro
- dependencies in activity could be format in simple way (like 'Require: pygames') and installer should resolve it to preper native package(s); on that way it demands common naming scheme alsroot 12:36, 13 January 2009 (UTC)
- ...
Contra
- that says nothing about installing activity itself alsroot 12:36, 13 January 2009 (UTC)
- ...