Activity Team/Packaging Ideas: Difference between revisions
No edit summary |
m moved Walter is a wanker 10/Packaging Ideas to Activity Team/Packaging Ideas over redirect: revert |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
<noinclude>{{ GoogleTrans-en | <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 | * 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 | It could be a meta package that is linked to frequently used dependencies (like csound/pygame/etc.). | ||
Pro | Pro | ||
* | * 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 | ||
* | * 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 35: | 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 | === Sugar is like Firefox and activities are like addons === | ||
Pro | Pro | ||
* Simplest version, what we have now. | * Simplest version, what we have now. | ||
Con | |||
* | * 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 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) | ||
=== 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) | 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 | 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) | (forward and backwards compatibility), linked against the right libraries (recursive dependencies) using a matching | ||
ABI (architecture dependency) | 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 | 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 | 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 | 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 | 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" | 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]] | ||