Activity Team/Packaging Ideas
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. Most activities rely on a standard set of Sugar dependencies like PyGTK, Squeak, GStreamer, and PyGame. But others have special dependencies which need to be installed on the target system before the activity can run.
- Install the activity itself.
- Blobs in activities. Some activities (Colors, Oficina, Bounce, WikiBrowse) include compiled code, like executables or Python extension modules.
- Should we build non-pure-python activities while installing, or use binary packages?
- And in general, how to treat a variety of platforms: x86, x86_64 and future ARM, MIPS?
Distro teams should take care of it
- thats enough for XO alsroot 12:36, 13 January 2009 (UTC)
- Many activities just rely on the standard Sugar dependencies, it's really just a few special ones.
- thats not enough for the rest of distros
each distro team has to work out the same work
like inventing theirs own mechanisms to treat activity dependencies etc. alsroot 12:36, 13 January 2009 (UTC)
Invent-own/reuse-existing packaging format
- Could possibly come up with a solution that works very well specifically for Sugar.
- A lot of work solving a problem has been solved already on each system.
- Might conflict with the target system's native package manager.
- Package managers tend to present confusing user interfaces to the user.
Sugar is like a Firefox and activities are like addons
- Simplest version, what we have now.
- what about variety of possible dependencies, should we pre-install them all ? alsroot 12:36, 13 January 2009 (UTC)
Use distro-specific activities installer
This is a kind of #Invent-own/reuse-existing packaging format packaging format, but it moves the center of gravity to a distro-specific installer from the packaged activity itself.
The activity.info file would include a list of dependency names which come from a predefined list. The distro-specific installer backend would be responsible for parsing the list and installing the correct dependencies.
- dependencies in activity could be format in simple way (like 'Require: pygames') and installer should resolve it to proper native package(s); on that way it demands common naming scheme alsroot 12:36, 13 January 2009 (UTC)
- that says nothing about installing activity itself alsroot 12:36, 13 January 2009 (UTC)