[Sugar-devel] [SLOBS] Oversight Board request: Not fully bundled .xo

[Aleksey Lim]

On Thu, Mar 04, 2010 at 10:20:11PM -0300, Bernie Innocenti wrote:
> On Thu, 2010-03-04 at 17:01 -0500, Benjamin M. Schwartz wrote:
> > Aleksey Lim wrote:
> > > * the major issue here that ASLO is not particalr deployment oriented
> > >   portal, e.g. in OLPC case, mentioned issue is mostly means nothing
> > >   since OLPC can effectively add/remove any component they think is
> > >   useful for their users
> > 
> > I don't understand this claim.  ASLO is seeing literally millions of
> > downloads from OLPC deployments.  Probably 99% of ASLO traffic is from
> > OLPC's users.
> 
> If we want Sugar's user-base to keep growing in the future, we need to
> keep our platform open and viable to users of different hardware.
> Hopefully soon, also OLPC is going to switch to a non-x86 architecture.
> 
> It was clear from the beginning that fossilizing on a single immutable
> ABI (32bit x86 + Fedora 9 + Sugar 0.82) was going to be a dead-end.
> 
> 
> > As for the rest... I think .xo bundles should be absolutely free of binary
> > executables, or anything else that depends on more than the Sugar
> > Platform.  We should then introduce a different (better!) bundle format
> > that supports such dependencies, based on 0bundle, 0install, etc.  As a
> > temporary codename, call it ".x0".
> 
> While I've always been advocating for using a package system in Sugar,
> I've not been doing any work in this direction. I'm enormously grateful
> to Aleksey for being a "doer" with his pioneering work on 0install.
> 
> My only concern is that 0install seems to be itself another prototype
> packaging format, with plenty of crucial features still missing. For
> example, Aleksey was telling me last week that people build binaries on
> their personal desktops because there's not yet a real build cluster
> like Koji or Suse buildservice.

..everything later is tech, discussable stuff and is not intended to be
approved by SLOBs..

yup it is a problem (and if we will follow 0install way we'll have to
have public farm), but my first 0install contribution was integrating
PackageKit into 0install thus let 0install ask native packaging systems
at first and later fallback to homemade blobs.

> Meanwhile, distros are repackaging our xo bundles into native rpms and
> debs... Are we sure we couldn't just sit and let the distros do their
> job? I'm convinced that the unprivileged installation issue is easy to
> overcome once we agree that native packages don't stink and are not more
> complicated than they need to be.

I hope you mean non-SP activities otherwise we don't need ASLO at all :)
but it has disadvantages as well e.g. if a kid created first(and simple)
Qt based activity (but Qt is not part of SP) the first thing which he
should do is following regular distro way to propose activity to *every*
sugar distro thus pretty not doable.

-- 
Aleksey