[IAEP] [Sugar-devel] [SLOBS] Long-term support for Sugar

[Benjamin M. Schwartz]

Bernie Innocenti wrote:
> 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.

I'm not thinking about Windows.  I'm thinking about Linux.  I don't use an
RPM-based distro, so I don't have the RPM tools lying around.  I'm not
especially comfortable with RPM or cpio archives, and I'm not sure how to
inspect or create them.  Same with .deb.

>> 2.  Tell the unpacked manifest at a glance without unpacking.
> 
> All package formats support this.

RPM does not, because of the pre/post scripts.  The scripts may generate
additional files.

>> 3.  Be sure that no untrusted code needs to be run to perform the
>> installation.
> 
> All package formats support this.

I did not say "support sometimes".  I said "be sure".  Simplicity, so that
it is possible to reason about the installation process, is a virtue.
Using some restricted subset of the features of some existing format is
certainly possible, but also creates enormous potential for confusion.

>  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.

And this request should be denied, as should dependency handling.

>> 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.

We are not going to solve the common real-world scenarios.  It is
impossible for us.  For example, we wish to operate on many different
distributions.  You know better than I that this means that we cannot rely
on dynamic linking with dependencies, which is the most common real-world
scenario.

What we can do is to create new, special, highly restricted scenarios, and
then demand that people package for them.  One such scenario that I
believe we can support with confidence is Activities written exclusively
in Python, using only functions from a static list of blessed modules.

>> 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.

I agree, switching bundle formats would gain us a lot of these features.
However, I don't think features such as dependency tracking are of much
use to us, because we can't trust system package managers, and we can't
afford to maintain our own complete distro and package database.

The closest I can come to agreeing with this claim is to suggest 0install
[1].  0install is a completely user-side package management system, with
support for multiple platforms, building from source, decentralized
storage, cryptographic bundle identification, and unprivileged
installation.  It also comes with its own bundle format.  The result is
almost as bad as maintaining our own parallel-installable distro, but at
least it's all already working.

[1] http://0install.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.sugarlabs.org/archive/iaep/attachments/20090921/ab8fb209/attachment-0001.pgp