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

[Bernie Innocenti]

El Mon, 21-09-2009 a las 21:27 -0400, Benjamin M. Schwartz escribió: 
> > (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.

With Python setup utils, it can be as easy as creating an xo bundle:

  ./setup.py bdist_rpm

or

  ./setup.py bdist_deb


You don't need to know more than this to match and exceed the
functionality of the bundleutils.

rpm is also available as a package for Debian-based distros, but dpkg is
not available for Fedora.


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

pre-post scripts are optional, rarely necessary, and can be disabled.
Moreover, packages are required to "own" files they create from scripts,
so you'd see them in the list output.

As a matter of fact, I dislike the practice of using scripts in packages
and I think it should be discouraged as much as possible.


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

It's a necessary trade-off.

You could obtain the desired feature set both by adding features to the
xo bundles or by subtracting unwanted features from the full-blown
package managers.

The problem with the first approach is that it would take maybe 10
man/years of work to get there.  And it would still result in
uncorrectable dishomogeneity between the OS and the activities.

So, all considered, which approach is worse?


> > 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 a few valid reasons for the former, and many compelling
reasons for the latter.

The current scheme is simply broken: it will create a compatibility
nightmare within a few years, even on a single OS distribution and CPU
architecture.  Besides, it doesn't offer enough modularity for complex
activities (GCompris) and forces developers of non-Python activities to
do resort to horrible kludges to embed their runtimes within the
bundles.

How do you propose to address *all* this issue without introducing
dependencies and a proper build system?


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

How does, for instance, Gimp manage to work perfectly on *all* Linux
distributions?  And how do all the other 19K packages in my distro
manage to find *exactly* all the dynamic libraries they need when they
are installed?

We don't have to do anything special, either.  Some Sugar activities
have already been natively packaged in the main Linux distributions.
They work as well as any other packaged application, and none of the
original authors need to be concerned about how this magic was
performed.


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

Sorry, I find this horribly restrictive.  My favorite educational
application, XaoS, would not even be possible in this scenario.  Neither
would Firefox, GCompris and many of the most popular activities that we
offer on activities.sugarlabs.org today.

With such a limitation, Sugar would be a really sad educational
environment.


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

Why not?

>  and we can't
> afford to maintain our own complete distro and package database.

Why would we have to?  Several good distros already exist... just pick
one.  No, actually, let's pick many!


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

It's pretty awesome... until you discover how it's done.

Something very similar in scope, but much larger quite different in
implementation, was already attempted a long time ago:

  http://www.desktoplinux.com/news/NS5197426928.html

Red Carpet was capable of installing a whole replacement Gnome desktop
on top of many distributions.

Of course, it was a disaster: the complexity grew with the number of
packages, distributions and possible upgrade paths.  It would break your
system in really interesting ways ;-)

0install seems cleaner and simpler, although on my system it failed to
install the Subversion package with some weird error after downloading a
bunch of packages.

I'd replace the current bundle format with this any day, but it's far
from being a solution.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/