344
edits
Changes
Jump to navigation
Jump to search
Line 49:
Line 49: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Activity Team/Packaging Ideas (view source)
Revision as of 07:28, 12 February 2009
, 07:28, 12 February 2009New proposal: Combined source+binary package
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 ==
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.
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
engineering, but [[User:Sascha_silbe|I]]MO trying to fit existing formats to our 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.
=== Package contents ===
* metadata (title, author, etc.)
* software dependency information
* hardware dependency information
* source code for all architecture-dependent files
* optional: source code for dependencies
* optional: prebuilt architecture-dependent files with a checksum of the source used at build time
* Rainbow security information
=== Software dependencies ===
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
ABI (architecture dependency) is used.
The easiest way to ensure this is to bundle all dependencies with the Activity. But this might have severe drawbacks:
* Bundles might get very large (imagine adding half of Gnome to Read)
* Installation might take several hours (think of building xulrunner on an XO)
* 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
contain a dependency tree with the following information for each entry:
* generic package name (usually the name chosen by the original author)
* minimum version
* maximum version
* 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
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
is available.
The dependency tree will get processed bottom up: each time a dependency cannot be met (not available, conflicts with
already-installed package, ...), all higher-level dependencies will need to get built from source as well (to make
sure the ABI matches).
=== Hardware dependencies ===
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
(but of course with the option to install anyway so it could be adapted to the available hardware).
=== Prebuilding ===
As building from source might take a significant amount of time, it might be useful (bundle size/build time tradeoff) to
ship with prebuilt architecture-dependent files.
Usually, each architecture can only build files for itself (native compilation), not for others (cross-compilation). To ensure
outdated files are rebuilt, a checksum of the source code used for building will be added. It doesn't need to be a cryptographic hash,
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
all to reduce download size.
[[Category:Activity]]
[[Category:Activity]]