[Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)
sascha-ml-ui-sugar-devel at silbe.org
Sun Nov 29 09:02:15 EST 2009
(Repost due to subscribers-only policy on sugar-devel)
On Sun, Nov 29, 2009 at 12:53:48PM +0100, Jonas Smedegaard wrote:
>>> Please note that comparing the list of missing dependencies provided
>>> by Michael Stone with the "components" listed in the "Sugar
>>> Platform" page, only EToys is missing.
>> That's good news. Which package does gst-plugins-espeak hide in? It's
>> still on my to-do list for sugar-jhbuild.
> It is not (yet) packaged for Debian, I believe. Oh, sorry if I missed
> out on that one...
Too bad, IIRC I had trouble building it from source. :-/
> And you might have misunderstood: I did not mean to say that all is
> well except EToys. Just that the Sugar Platform" page seems to be
> not enough to avoid surprises/frustrations.
> Example: When that page states that GStreamer can be expected, does
> that then mean core GStreamer infrastructure, core CStreamer + Python
> bindings, common GStreamer (whatever that really is) + Python
> bindings, or any and all weird GStreamer extensions (that is packaged
> for Fedora).
You are absolutely right that the page is quite ambiguous in general.
And like others parts of Sugar, there's still quite some Fedoraism. Help
to fix that greatly appreciated.
I'm moving the thread to sugar-devel for clarifications.
I think the Sugar Platform page  should list upstream source
packages; unless explicitly noted otherwise activity authors can expect
a) Python bindings,
b) executables and
c) data files
provided by the (upstream-)default configuration are installed. Once
0install support gets merged, Sugar Platform should be enhanced to
include build tools (autocrap, c(++) compiler, ...); in that case,
activity authors can also rely on the corresponding -dev(el) packages
(i.e. libraries, header files, etc.) to be installed as well.
If there's anything most distros leave out that's included in the
upstream defaults, it should be mentioned in the list (i.e. removed from
the Sugar Platform). For a single distro (e.g. Debian disabling
something Fedora ships) it should be discussed on sugar-devel first.
As for the special case of gstreamer, I'd say it should include
gstreamer-plugins-good (AFAICT that's an upstream distinction, so
distro-agnostic), but not -bad or even -ugly. Especially MP3 support
should be kept out (until after all patents have expired, whenever that
might be) of the Sugar Platform, as it is a minefield of legal issues.
>> Python 2.5/2.6
> Authors should then know that "well-written" implies "must only use
> functions supported by *both* Python 2.5 and Python 2.6".
>> Gtk+ 2.16
> Debian have moved on to GTK+ 2.18 in Sid, and do not offer the older
> library as an alternative.
Personally I consider the list as "minimum version", not "exact version"
(given current distro practices it cannot be the latter). Yes, activity
authors should be (made) aware of that and cater for the consequences
(which isn't exactly easy, but a different topic).
>> GStreamer 0.10
>> gstreamer 0.10.14
> Huh?!? I guess the capitalized is an ABI and the lowercased one is the
> actual implementation. So a Sugar Platform must include a
> specific micro version of the actual implementation of GStreamer?!?
Looks like a mistake to me.
(*) There is a way for individual users to legally acquire and use the
Fluendo MP3 decoder, but not for (package / image / whatever)
distributors (due to patent license restrictions). So as long as any MP3
patent is valid, SoaS cannot legally include an MP3 decoder (only an
installer for it, which would require an internet connection during
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 489 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20091129/86614609/attachment.pgp
More information about the Sugar-devel