Difference between revisions of "Sugar"

From ArchWiki
Jump to: navigation, search
m (Getting Started: renamed group)
m (Building a Modular Group: renamed an app)
Line 43: Line 43:
 
  python-cjson :-> [community]
 
  python-cjson :-> [community]
 
  python-telepathy :-> [community]
 
  python-telepathy :-> [community]
  gst-plugins-espeak :-> [unsupported]
+
  gstreamer0.10-espeak :-> [unsupported]
 
  olpcsound :-> [unsupported]
 
  olpcsound :-> [unsupported]
 
  telepathy-glib :-> [community]
 
  telepathy-glib :-> [community]

Revision as of 10:48, 26 June 2009


Introduction

A product of the OLPC initiative, Sugar is a Desktop Environment akin to KDE and GNOME, but geared towards children and education. If you have a young son, daughter, brother, sister, puppy or alien, the best way to introduce them to the world of Arch Linux is by deploying an Arch/Sugar platform and then forgetting about it. That's the beauty of Arch Linux (TM) - Deploy and Forget (But Know How to Deploy).

But wait..where art thou, O Sugar?

That's right. To lead such a good life, you need at least some Sugar-related packages in at least AUR.

Getting Started

I have begun noting down the dependencies, and if I do get the time to complete scripting the entire sugar-desktop group, I will put them all up on AUR as soon as I am able to.

"I hope we can remove these first-person references soon" -- schiv on himself

And yes, YOU should not be lazy and carry on independently from the information herein.

Building a Bundle

This is a cool build system provided by the developers that allows one to download and build Sugar almost in its entirety. You will be told what you need, and of course, it will not help if what you need has not yet been packaged for us mighty Archers.

The resulting project can then be offered as a bundle. This method of building should not be encouraged, since it is not "modular". A likely analogy is the easy-e17 script, except that we are in the opposite situation whereby there are no modular packages and thus no group - yet. Adding the provision is a safety measure, .eg:

pkgname=sugar-bundle
pkgdesc="The Sugar environment and applications built with jhbuild"
provides=('sugar-desktop') # as in provides=('e')
conflicts=('sugar-desktop')

But as soon as someone uploads a component of the build/Sugar as a separate package, it must be part of the group (and the bundle package will automatically conflict), eg.:

pkgname=sugar-toolkit
pkgdesc="The Sugar environment toolkit"
groups=('sugar-desktop' 'sugar-desktop-base')

Building a Modular Group

This is the more appropriate route to take. Here is the current list of noted dependencies, acquired by inspecting the build trees of distributions supported by Sugar (Gentoo in particular):

# Syntax: pkgname .. :-> location + comment1 + comment2 ..

espeak			 :-> [community]
squeak			 :-> [unsupported] + outdated + needs patching for sugar
evince			 :-> [extra] + needs patching for sugar
pyabiword		 :-> [unsupported]
python-cjson		 :-> [community]
python-telepathy	 :-> [community]
gstreamer0.10-espeak	 :-> [unsupported]
olpcsound		 :-> [unsupported]
telepathy-glib		 :-> [community]
xulrunner		 :-> [extra]
telepathy-gabble	 :-> [community]
telepathy-salut		 :-> [community]
hippo-canvas		 :-> [unsupported]

And the bash-fu to install all existing packages (if you have saved the above in a file called sugar.todo):

~# pacman -S $(grep ":->" sugar.todo | grep -v unsupported | awk '{print $1}')

The above basically filters the output, first matching a string with grep, then leaving out matches with grep -v, and finally showing only the first coloumn of stdout with awk.

The following are "Level 2" dependencies:

abiword-devel		 :-> [unsupported] + required by pyabiword

The Applications

From inspection of build trees and the Sugar Wiki, the following appear to be the Sugar components that we should be distributing:

hulahop
sugar-toolkit
datastore
presence-service
sugar
sugar-base
artwork
imageviewer-activity
web-activity
log-activity
terminal-activity
turtleart-activity
etoys
chat-activity
pippy-activity
read-activity
calculate
jukebox
write

Things to ponder about:

  • Should we prepend "sugar" to all the individual packages (some of the names are pretty generic) eg.sugar-hulahop?
    • Even if the name has not been taken by another package in the repos/AUR?