[Sugar-devel] Hypothetical sugar-0.90 material, draft 1.

[Aleksey Lim]

On Thu, Jun 10, 2010 at 02:28:01PM -0400, Martin Langhoff wrote:
> On Thu, Jun 10, 2010 at 1:41 PM, Benjamin M. Schwartz
> <bmschwar at fas.harvard.edu> wrote:
> > In my view, OLPC's ARM announcement creates a pressing problem of avoiding
> > total confusion and fragmentation between different CPU architectures.
> > 0install is, in my view, the most promising candidate solution.
> 
> I agree that the problem of multiple arches exists. But you can refer
> to the lengthy thread about 0install about the nasty tradeoffs
> involved.
> 
> No intention to rehash a controversial topic here :-)

No intension to fallback to another useless discussion. Just want
to synchronize what other people think with what I'm thinking they think.

---

So, what the object...

The code:
1.1) Sugar Platform dependencies i.e. bunch of required libraries/applications
     like glibc and xulrunner etc.
1.2) Sucrose
1.3) Sugar Objects (to not separate to activities and documents, since
     some time it is hard e.g. TA objects or Etoys projects).
1.4) Sugar Objects dependencies that are not part of Sugar Platform
     could be various libraries or activities (e.g. TA for TA objects)

Who might distribute this code:
2.1) GNU/Linux distribution from native packages
2.2) sugar deployments like OLPC that use the same mechanisms like
     distros but provide additional packages/QA/support efforts
2.3) directly from creator

Where this code could be used:
3.1) on XO deployed by particular distributor with sugar installed
3.2) on regular GNU/Linux desktop with some kind of sugar support

About subject...

I hope I won't be failed if say that ideal sugar user is doer.

---

And most popular scheme should be 1.3(4) - 2.3 - 3.*. In most cases for
Sugar Objects and in less cases for activities (but still important) and
its dependencies (like if some one created convenience math library).
Trying to push this flow via 2.1 (less in 2.2) makes the flow much
smaller. And tool like 0install lets us follow 2.3.

At the same time 0install is not intended to cover all possible
variants i.e. not "lets switch all sugar deployments to 0install".
For example for all sugar deployments regular GNU/Linux distribution way
is more preferable.

One of core benefits of 0install is that is lets us reuse 2.1 and 2.2
e.g. if someone tying to launch Vnc activity, sugar will popup window
with suggestions to install native vnc package.

---

Back to original purpose of this post, are people who disagree with
0install (which is just an instrument), are disagree with particular
instrument or with 1.3(4) - 2.3 - 3.* scheme itself (or think it is
not so important to make not trivial things to rich it).

-- 
Aleksey