[Sugar-devel] The ARM is near

[Tomeu Vizoso]

2009/8/29 Philippe Clérié <philippe at gcal.net>:
> 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.

So is the only problem what we are calling Sugar today? If we rename
SoaS to Sugar and Sugar to Sucrose, how we would be solving anything?

Thanks,

Tomeu

> 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
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning