Difference between revisions of "Activity Team/Packaging Ideas"
Jump to navigation
Jump to search
(Clean up a bit, fill in some information.) |
|||
| Line 1: | Line 1: | ||
| − | = | + | = 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. 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 = | = Proposal schemas = | ||
| − | |||
| − | == Distro teams should take care | + | == 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- | + | == 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 == | ||
| − | + | 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 12: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)