[Sugar-devel] The ARM is near

[Philippe Clérié]

Why not treat Sugar as a distribution in its own right. As in: Sugar 
is a GNU/Linux distribution with Sucrose as it's user interface. It 
seems to me you're generally drifting in that direction. With Soas 
it's now treated more or less as a spin/remix so it's not that much 
of an extension.

As an outright distribution, you only have to support you, but the 
software is still free, so others can create their own 
distributions/spins pretty the same way there is an OpenSuse based 
Soas.

Having a target distribution ipso facto gives you target versions 
for your dependencies. If version 10.03.2A is what's available then 
that's what activity developers should use. If others want to use 
10.04.0 then it's up to them to send patches upstream.

You can use the base distribution's infrastructure for package 
installation, support, bug fixes and compatibility with other 
architectures.

None of this is new. That's pretty much what's being done already. 
Except that nobody is calling Sugar a GNU/Linux distribution.

Cheers,
Philippe

-- 


Philippe

------
The trouble with common sense is that it is so uncommon.
<Anonymous>

On Friday 28 August 2009 08:03:18 Benjamin M. Schwartz wrote:
> Martin Langhoff wrote:
> > On Fri, Aug 28, 2009 at 12:33 PM, Tomeu 
Vizoso<tomeu at sugarlabs.org> wrote:
> >> Yeah, I guess Jonas' suggestion of promoting platform
> >> independent bundles as "first class" addresses this concern.
> >
> > +1
> >
> >> I personally don't think we are going to be able to outdo rpms
> >> nor debs so the less binary code we have the better.
> >
> > Agreed. One thing we _could_ do, without getting into the whole
> > mess, is to have a 'requires' metadata that gives the Sugar
> > shell some hints.
> >
> > The shell can then
> >
> >  - attempt to install rpm/debs to satisfy the req's... if it
> > can (dependent on sudo access, network access, and the
> > collaboration of the underlying pkg manager)
>
> This doesn't solve the problem.  Packages on the same arch, with
> the same name, ostensibly representing the same version of the
> same software, will often have substantially different ABI in
> different distros due to the choice of compile-time options.
>
> Even ignoring this phenomenon, different distros ship different
> versions of underlying libraries.  If your dependency is too
> recent, the user can't acquire it, and so can't run your code. 
> If your dependency is too old, the version on this distro may
> have an API break that breaks your application.
>
> We cannot solve our problem by relying on the distros, unless we
> want every Activity to be repackaged and retested separately for
> every version of every distro.  My goal is to make Activity
> bundles universal across Sugar.  The only way to do this is to
> control the dependency chain ourselves, outside of the distro.
>
> --Ben