[Sugar-devel] safer customization key (was Re: will the one true browse please stand up?)
David Farning
dfarning at sugarlabs.org
Sat Aug 1 13:05:41 EDT 2009
On Sat, Aug 1, 2009 at 8:47 AM, Daniel Drake<dsd at laptop.org> wrote:
> 2009/8/1 Tomeu Vizoso <tomeu at sugarlabs.org>:
>> What do you propose doing?
>
> Leaving packaging to the experts (the distributions) and focusing on
> being a good upstream -- only stepping into the packaging areas where
> the distro people are lacking.
>
> I think activities should be packaged by distros and we should use
> their standard systems, which have already solved this class of
> problem 5 times over.
We need to be careful about considering what class of problem each
packaging method is trying to solve.
The goal for traditional packaging methods was to ensure dependencies
were being met, turning 'config; make; install' into a simpler
operation, and doing various pre and post install configuration.
This goal is inline with a core set of sugar packages.
The goals of .xo files are rather different. For standard .xo bundle
all of the dependcies should already be met. 'Config, make, install'
is handled by bundle registry. .Xo files never interact directly with
the underlying system. They only use Sugar, gnome, python, apis which
should be guaranteed present by the core sugar dependences. This is
very similar to the notion of pearl and python modules.
On the flip side, traditional distro package methods require root
access. .xo bundles are install within sugar space. Thus they can be
installed by the user. This is similar to Mozilla addons. Mozilla
uses another class of 'packages' called plugins. These are a bit more
complicated these are a bit more complicated because plugins add
additional system level functionality. Plugins are usually repackaged
for Linux by the distros to ensure dependences are met.
Have you followed the work alsroot is doing on the bundle registry?
It is starting to provide some very good and consistent APIs for
working with bundles.
david
More information about the Sugar-devel
mailing list