El Mon, 21-09-2009 a las 19:13 -0400, Benjamin M. Schwartz escribió: > 1. Produce them easily on any platform.
At OLPC, I head this argument made many times, but it's moot: (1) one could create a bundle on Windows, but not test it. Since actual development requires a system capable of running Sugar anyway, you can as well depend on its native tools. (2) so far, how many of the 190 activities available from activities.sugarlabs.org were created on Windows (or Mac OS X)? (3) why would we want to cripple our system architecture to encourage the use of proprietary platforms for authoring Sugar content? > 2. Tell the unpacked manifest at a glance without unpacking. All package formats support this. > 3. Be sure that no untrusted code needs to be run to perform the > installation. All package formats support this. rpm and deb optionally allow executing pre/post-installation scripts, which are not necessary for the majority of applications and can also be disabled. Actually, the ability to run scripts on installation is often requested by authors of content bundles. > There are many more things, mostly related to the dramatic simplicity of JAR. Anyone likes simplicity, but jar files with no dependencies are really a *simplicistic* solution that doesn't work even in the most common real-world scenarios. All Linux package formats are nothing but common archives with an additional metadata header pre-pended. Such metadata would be easy to retrofit to xo bundles, but the tools that do something sensible with it would take years to develop. > I don't understand how switching bundle formats for Activities would win > us anything. As I explained a few messages ago, using one of the existing package formats would enable us to use the existing package tools. Which we need in order to support a number of common features such as inter-package dependencies, multiple architectures, system upgrades, package signing... way too many to list them all. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel