Activity Team/Packaging Ideas

Goal

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?

Proposal schemas

Distro teams should take care of it

Pro

• 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.

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-existing packaging format

Pro

• Could possibly come up with a solution that works very well specifically for Sugar.

Contra

• 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

Pro

• Simplest version, what we have now.

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

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.

Pro

• 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)

Contra

• that says nothing about installing activity itself alsroot 12:36, 13 January 2009 (UTC)