Line 1: |
Line 1: |
− | = Goal = | + | <noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}</noinclude> |
| + | {{TOCright}} |
| + | == 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 activities.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 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. | | * Install the activity itself. |
Line 10: |
Line 12: |
| ** And in general, how to treat a 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 of it == | + | === Distro teams should take care of it === |
| | | |
| It could be a meta package which is linked to frequently used dependencies(like csound/pygame/etc). | | It could be a meta package which is linked to frequently used dependencies(like csound/pygame/etc). |
Line 23: |
Line 25: |
| * thats not enough for the rest of distros <br> each distro team has to work out the same work <br> like inventing theirs own mechanisms to treat activity dependencies etc. [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC) | | * thats not enough for the rest of distros <br> each distro team has to work out the same work <br> like inventing theirs own mechanisms to treat activity dependencies etc. [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC) |
| | | |
− | == Invent-own/reuse-existing packaging format == | + | === Invent-own/reuse-existing packaging format === |
| | | |
| Pro | | Pro |
Line 33: |
Line 35: |
| * Package managers tend to present confusing user interfaces to the user. | | * 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 |
Line 41: |
Line 43: |
| * 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. | | 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. |
| | | |
Line 53: |
Line 55: |
| | | |
| | | |
− | == combined Source+Binary package == | + | === combined Source+Binary package === |
| | | |
| This is a new package format fitted to the special needs of Sugar. Unlike Java (where - at least in theory - compiled bytecode | | This is a new package format fitted to the special needs of Sugar. Unlike Java (where - at least in theory - compiled bytecode |
Line 64: |
Line 66: |
| cause more trouble long-term. If designed properly, it might even get used as a standard interchange format for other systems. | | cause more trouble long-term. If designed properly, it might even get used as a standard interchange format for other systems. |
| | | |
− | === Package contents === | + | ==== Package contents ==== |
| * metadata (title, author, etc.) | | * metadata (title, author, etc.) |
| * software dependency information | | * software dependency information |
Line 73: |
Line 75: |
| * Rainbow security information | | * Rainbow security information |
| | | |
− | === Software dependencies === | + | ==== Software dependencies ==== |
| Dependencies are a rather hard problem. We need to ensure that the right package (naming) in exactly the right version | | Dependencies are a rather hard problem. We need to ensure that the right package (naming) in exactly the right version |
| (forward and backwards compatibility), linked against the right libraries (recursive dependencies) with a matching | | (forward and backwards compatibility), linked against the right libraries (recursive dependencies) with a matching |
Line 102: |
Line 104: |
| required by a lot of Activities). The security implications of this need to be carefully considered, though. | | required by a lot of Activities). The security implications of this need to be carefully considered, though. |
| | | |
− | === Hardware dependencies === | + | ==== Hardware dependencies ==== |
| | | |
| Some Activities require special hardware (e.g. sensor module) or are known not to work on certain (sets of) architectures, e.g. | | Some Activities require special hardware (e.g. sensor module) or are known not to work on certain (sets of) architectures, e.g. |
Line 108: |
Line 110: |
| (but of course with the option to install anyway so it could be adapted to the available hardware). | | (but of course with the option to install anyway so it could be adapted to the available hardware). |
| | | |
− | === Prebuilding === | + | ==== Prebuilding ==== |
| | | |
| As building from source might take a significant amount of time, it might be useful (bundle size/build time tradeoff) to | | As building from source might take a significant amount of time, it might be useful (bundle size/build time tradeoff) to |
Line 119: |
Line 121: |
| all to reduce download size. | | all to reduce download size. |
| | | |
− | == Sugar Platform == | + | === Sugar Platform === |
| | | |
| Maybe most reasonable decision(at least for 0.84) is declaring "Sugar Platform" like a set of all non-sugar components that activity developers could rely on. | | Maybe most reasonable decision(at least for 0.84) is declaring "Sugar Platform" like a set of all non-sugar components that activity developers could rely on. |
| | | |
| [[Category:Activity]] | | [[Category:Activity]] |