[Sugar-devel] About the need for .xo bundles (again) (was Re: safer customization key (was Re: will the one true browse please stand up?))
alsroot at member.fsf.org
Thu Dec 17 07:48:01 EST 2009
On Tue, Aug 04, 2009 at 02:18:01PM +0100, Martin Dengler wrote:
> On Sun, Aug 02, 2009 at 10:10:59PM +0545, Daniel Drake wrote:
> > 2009/8/1 Tomeu Vizoso <tomeu at sugarlabs.org>:
> > > They haven't solved the problems we want to solve and are probably not
> > > even interested in trying. I'm a bit suprised you are not aware of
> > > this, there was a whole session dedicated to this in the last FUDCon
> > > in boston. Anyone has a link to the minutes?
> > Which problems are those?
> , perhaps:
One of consequences of
in my mind, is that Services nearly solve all problems that poke people
think about extending/replacing .xo bundles.
The major thing that is missed - successful using of Services
requires internet connection, but theres is
and chance for big deployments to run 0install mirrors(so, user can use
only local network access to satisfy all their needs).
> XO design goals not currently satisfied by RPM
> 1. Installing by "getting from a friend"
if activity is pure python there is no problems in any case,
in case of external deps or platform specific binaries
0install will let download/build missed deps by demand after "getting
from a friend"
> 2. Kids can change and redistribute bundles.
> 1. Kid bundles are "first class" (distributed versioning implies
> distributed dependencies)
packaged activities IMO is anachronism
> 3. Don't break the world at install time
0install is all about this,
there is no(in regular cases) chances to break system,
every 0install package goes to ~ directory and will be used only by
activity that requires it
> 4. Localizability in the absence of a cantralized repo
thats another case that 0install was intended to solve by its design
(its a decentralized deployment system).
> 5. Novice programmers using [Pippy]
> 1. Should activities be noarch?
with Services, activities itself have a chance to be noarch all time
even in case of GCompris, .xo bundles with such activities will be
noarch and contain only links to places where proper binary could be
grab(or links to sources for last case)
> • Short-term -- XO format not going away because of requirements not in RPM or
> any other package format.
> • Other problems underneath -- development standards for activity developers.
> (What is testing, what is release.)
> • This is the release, pull it from git, and build an installable package ==
> something that helps XO and RPM potentially.
More information about the Sugar-devel