[Sugar-devel] Sugar Platform clarifications (was: Re: [Debian-olpc-devel] Missing deps for sucrose-0.86.)

Jonas Smedegaard dr at jones.dk
Sun Nov 29 11:37:44 EST 2009


On Sun, Nov 29, 2009 at 03:02:15PM +0100, Sascha Silbe wrote:
>(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. :-/

Ask me nice and I'll do it :-) Please ask at the Alioth list, not here.


>I think the Sugar Platform page [1] should list upstream source 
>packages; unless explicitly noted otherwise activity authors can 
>expect that
>a) Python bindings,
>b) executables and
>c) data files
>provided by the (upstream-)default configuration are installed.

Makes sense to me: that is sufficient for arch-independent scripting 
code to work.  Development headers are required only for _distro_ 
developers.

I think, however, that it makes sense to explicitly list the Python 
bindings that are expected, as version numbers are often not in sync, 
and sometimes multiple incompatible wrappers exist.

It might even make sense to *only* list the Python wrappers - their 
underlying libraries cannot be linked against directly 
arch-independently anyway.


>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.

I have not followed the discussions on 0install, but it surprises me 
that this should be mandatory - I always considered 0install as 
comparable to a distribution.

I might loose interest in Sugar if 0install becomes integral part of 
core Sugar.  But that's another discussion.


>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. (*)

Makes sense.  And -good is also listed already, so I whined a bit too 
much.


>>>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).

Makes sense to me.

I have now updated the "Sugar Platform" page to say "Minimum version" 
and drop the superfluous/confusing newer versions mentioned for Python 
and CSound.


>>>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.

I've now merged those entries.



>[1] http://wiki.sugarlabs.org/go/0.86/Platform_Components
>(*) 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 installation).
>
>CU Sascha
>
>-- 
>http://sascha.silbe.org/
>http://www.infra-silbe.de/



>_______________________________________________
>Sugar-devel mailing list
>Sugar-devel at lists.sugarlabs.org
>http://lists.sugarlabs.org/listinfo/sugar-devel


-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20091129/870a3b50/attachment.pgp 


More information about the Sugar-devel mailing list