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

[Peter Robinson]

On Tue, Sep 22, 2009 at 2:27 AM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> 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.

Its called a manual.

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

In Fedora at least that is not the case. Pre and Post scriptes are
used to do things like poke ldconfig and the like. I'm pretty sure its
against package guidelines to generate files except in specific cases
like the kernel.... and that case is gone with Fedora 12.

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

Why? So you get simplicity and breakage.... most of the sound based
applications ship binaries.... in this case they will just break
between versions with no way of telling.... I take it your going to
offer to support the users?

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

That's possible but is not the case at the moment and I know from
experience that problem is getting worse.

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

I don't think you can make that judgement actually. I find with a lot
of the binary crap that's starting to appear in activities its
actually hard to trust the what the activity authors are bundling.

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

So is PackageKit

Peter