Line 1: |
Line 1: |
− | <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> | + | <noinclude>{{GoogleTrans-en}}</noinclude> |
| {{TOCright}} | | {{TOCright}} |
| == Goal == | | == Goal == |
− | Installing activities on every sugarized GNU/Linux distribution (not only XO) | + | Installing activities on every sugarized GNU/Linux distribution (not only the XO) |
− | just by clicking on icon in activities.sugarlabs.org. | + | just by clicking on an icon in activities.sugarlabs.org is the goal. |
| | | |
| == 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 that need to be installed on the target system before the activity can run. |
| * Install the activity itself. | | * Install the activity itself. |
| ** Blobs in activities. Some activities (Colors, Oficina, Bounce, WikiBrowse) include compiled code, like executables or Python extension modules. | | ** Blobs in activities. Some activities (Colors, Oficina, Bounce, WikiBrowse) include compiled code, like executables or Python extension modules. |
Line 16: |
Line 16: |
| === 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 that is linked to frequently used dependencies (like csound/pygame/etc.). |
| | | |
| Pro | | Pro |
− | * thats enough for XO [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC) | + | * That's enough for the 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. | | * Many activities just rely on the standard Sugar dependencies, it's really just a few special ones. |
| | | |
| Contra | | Contra |
− | * 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) | + | * That's not enough for the rest of the distros <br> each distro team has to work out the same work <br> like inventing their 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 === |
Line 41: |
Line 41: |
| | | |
| Con | | Con |
− | * what about variety of possible dependencies, should we pre-install them all ? [[User:Alsroot|alsroot]] 12:36, 13 January 2009 (UTC) | + | * What about the 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. |
| | | |
− | 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. | + | 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 formatted in a simple way (like 'Require: pygames'), and the installer should resolve it to the proper native package(s); in that way, it demands a 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) |
| | | |
| | | |
| === 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 |
− | suffices), we need to cope with architecture-dependent files. | + | suffices); we need to cope with architecture-dependent files. |
| | | |
| Some of the ideas are already mentioned in other solutions outlined above, but each on its own doesn't solve the whole problem. | | Some of the ideas are already mentioned in other solutions outlined above, but each on its own doesn't solve the whole problem. |
| | | |
− | Using a whole new format (even if recycling parts of other formats, e.g. the current Bundle format) will require some | + | Using a whole new format (even if recycling parts of other formats, e.g., the current Bundle format) will require some |
− | engineering, but [[User:Sascha_silbe|I]]MO trying to fit existing formats to our will take nearly as much time near-term and | + | engineering, but [[User:Sascha_silbe|I]]MO trying to fit existing formats to ours will take nearly as much time near-term, and |
− | 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 ==== |
Line 77: |
Line 77: |
| ==== 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) using a matching |
− | ABI (architecture dependency) is used. | + | ABI (architecture dependency). |
| | | |
| The easiest way to ensure this is to bundle all dependencies with the Activity. But this might have severe drawbacks: | | The easiest way to ensure this is to bundle all dependencies with the Activity. But this might have severe drawbacks: |
Line 85: |
Line 85: |
| * old, buggy versions of libraries might get used (can be quite annoying) | | * old, buggy versions of libraries might get used (can be quite annoying) |
| | | |
− | Thus is makes sense to let at least some of the dependencies get handled by the underlying OS. The new bundle format will | + | Thus, it makes sense to let at least some of the dependencies get handled by the underlying OS. The new bundle format will |
| contain a dependency tree with the following information for each entry: | | contain a dependency tree with the following information for each entry: |
| * generic package name (usually the name chosen by the original author) | | * generic package name (usually the name chosen by the original author) |
Line 92: |
Line 92: |
| * source code URL (optional, but recommended) | | * source code URL (optional, but recommended) |
| | | |
− | Part of the installer will be OS-dependent: the generic name needs to be translated to an OS specific one (e.g. according | + | Part of the installer will be OS-dependent: the generic name needs to be translated to an OS specific one (e.g., according |
− | to Debian Python Policy) and dependencies need to be resolved (e.g. via apt for Debian). If there's internet connectivity, | + | to Debian Python Policy) and dependencies need to be resolved (e.g., via apt for Debian). If there's Internet connectivity, |
− | it might try to download the source from the given URL (advanced voodoo: check for new versions as well) if no OS package | + | it might try to download the source from the given URL (advanced voodoo: check for new versions as well), if no OS package |
| is available. | | is available. |
| | | |
Line 106: |
Line 106: |
| ==== 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., |
− | because the code is not 64bit-clean. When trying to install an Activity, it's better to warn the user about this than wasting his/her time | + | because the code is not 64-bit-clean. When trying to install an Activity, it's better to warn the user about this than wasting his/her time |
− | (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 ==== |
Line 118: |
Line 118: |
| just ensure that source changes cause a rebuild. | | just ensure that source changes cause a rebuild. |
| | | |
− | Sites like addons.sugarlabs.org might provide several packages, each prebuilt for a different platform (using buildbots) or none at | + | Sites like activities.sugarlabs.org might provide several packages, each prebuilt for a different platform (using buildbots), or none at |
| 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" to be a set of all non-sugar components that activity developers could rely on. |
| | | |
| [[Category:Activity Team]] | | [[Category:Activity Team]] |
| [[Category:Idea]] | | [[Category:Idea]] |