Activity Team/Packaging Ideas: Difference between revisions
m Activity Team/PackagingIdeas moved to Activity Team/Packaging Ideas: deCamel casing |
No edit summary |
||
| 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 | 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]] | ||