Activity Team/Packaging Ideas

From Sugar Labs
< Activity Team
Revision as of 13:36, 13 January 2009 by Wade (talk | contribs) (Clean up a bit, fill in some information.)
Jump to: navigation, search

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)