Activity Team/Packaging Ideas - Revision history

Patrol: moved Walter is a wanker 10/Packaging Ideas to Activity Team/Packaging Ideas over redirect: revert

2010-02-24T01:43:39Z

moved Walter is a wanker 10/Packaging Ideas to Activity Team/Packaging Ideas over redirect: revert

← Older revision	Revision as of 21:43, 23 February 2010
(No difference)

Page move vandal: moved Activity Team/Packaging Ideas to Walter is a wanker 10/Packaging Ideas: Walter is a wanker

2010-02-24T00:20:11Z

moved Activity Team/Packaging Ideas to Walter is a wanker 10/Packaging Ideas: Walter is a wanker

← Older revision	Revision as of 20:20, 23 February 2010
(No difference)

FGrose at 22:16, 6 August 2009

2009-08-06T22:16:56Z

Dennis Daniels: /* Sugar is like a Firefox and activities are like addons */

2009-08-06T21:46:34Z

Sugar is like a Firefox and activities are like addons

← Older revision		Revision as of 17:46, 6 August 2009
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 a Firefox and activities are like addons ===		=== Sugar is like Firefox and activities are like addons ===

	Pro		Pro
	* Simplest version, what we have now.		* Simplest version, what we have now.

	~~Contra~~		Con
	* 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)

FGrose at 14:39, 9 June 2009

2009-06-09T14:39:11Z

← Older revision		Revision as of 10:39, 9 June 2009
Line 126:		Line 126:

	[[Category:Activity Team]]		[[Category:Activity Team]]
			[[Category:Idea]]

Alsroot: rename category Activity to Activity_Team

2009-03-20T11:27:24Z

rename category Activity to Activity_Team

← Older revision		Revision as of 07:27, 20 March 2009
Line 125:		Line 125:
	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 Team]]

FGrose at 19:35, 17 March 2009

2009-03-17T19:35:12Z

← Older revision		Revision as of 15:35, 17 March 2009
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]]

FGrose: Activity Team/PackagingIdeas moved to Activity Team/Packaging Ideas: deCamel casing

2009-03-17T19:30:35Z

Activity Team/PackagingIdeas moved to Activity Team/Packaging Ideas: deCamel casing

← Older revision	Revision as of 15:30, 17 March 2009
(No difference)

FGrose: ActivityTeam/PackagingIdeas moved to Activity Team/PackagingIdeas: deCamel casing

2009-03-17T19:28:26Z

ActivityTeam/PackagingIdeas moved to Activity Team/PackagingIdeas: deCamel casing

← Older revision	Revision as of 15:28, 17 March 2009
(No difference)

Alsroot: /* Sugar Platform */

2009-02-25T14:41:20Z

Sugar Platform

← Older revision		Revision as of 10:41, 25 February 2009
Line 119:		Line 119:
	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]]

← Older revision		Revision as of 18:16, 6 August 2009
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]]