Difference between revisions of "Activity Team/Packaging Ideas"

From Sugar Labs
Jump to: navigation, search
(Use distro-specific activities installer)
(Clean up a bit, fill in some information.)
Line 1: Line 1:
= Purpose =
+
= Goal =
 
Installing activities on every sugarized GNU/Linux distribution(not only XO)
 
Installing activities on every sugarized GNU/Linux distribution(not only XO)
 
just by clicking on icon in addons.sugarlabs.org.
 
just by clicking on icon in addons.sugarlabs.org.
  
 
= Problems to solve =
 
= Problems to solve =
* install proper dependencies
+
* 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 activity itself
+
* Install the activity itself.
** blobs in activities
+
** 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
+
** 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
+
** And in general, how to treat a variety of platforms: x86, x86_64 and future ARM, MIPS?
* ...
 
  
 
= Proposal schemas =
 
= Proposal schemas =
...
 
  
== Distro teams should take care about it ==
+
== Distro teams should take care of it ==
...
 
  
 
Pro
 
Pro
 
* thats enough for XO [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC)
 
* thats enough for XO [[User:Alsroot|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
 
Contra
 
* thats not enough for rest of distros <br> each distro team has to work out the same work <br> like inventing theirs own mechanisms to treat activities dependencies etc. [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC)
 
* thats not enough for rest of distros <br> each distro team has to work out the same work <br> like inventing theirs own mechanisms to treat activities dependencies etc. [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC)
* ...
 
  
== Invent-own/reuse-exists packaging format ==
+
== Invent-own/reuse-existing packaging format ==
...
 
  
 
Pro
 
Pro
* ...
+
* Could possibly come up with a solution that works very well specifically for Sugar.
  
 
Contra
 
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 ==
 
== Sugar is like a Firefox and activities are like addons ==
...
 
  
 
Pro
 
Pro
* ...
+
* Simplest version, what we have now.
  
 
Contra
 
Contra
 
* what about variety of possible dependencies, should we pre-install them all ? [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC)
 
* what about variety of possible dependencies, should we pre-install them all ? [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC)
* ...
 
  
 
== Use distro-specific activities installer ==
 
== 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
+
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
 
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 [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC)
 
* 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 [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC)
* ...
 
  
 
Contra
 
Contra
 
* that says nothing about installing activity itself [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC)
 
* that says nothing about installing activity itself [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC)
* ...
 
 
== ... ==
 
  
 
[[Category:Activity]]
 
[[Category:Activity]]

Revision as of 13:36, 13 January 2009

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)