[Sugar-devel] The ARM is near
tomeu at sugarlabs.org
Sat Aug 29 08:31:38 EDT 2009
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
> 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
> 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?
> The trouble with common sense is that it is so uncommon.
> 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.
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
More information about the Sugar-devel