[Debian-olpc-devel] Bug#563436: sugar-0.88: sugar depends on python-numpy and python-pygames

[Jonas Smedegaard]

On Mon, Jan 04, 2010 at 06:19:57PM -0600, David Farning wrote:
>On Mon, Jan 4, 2010 at 2:02 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>> On Mon, Jan 04, 2010 at 01:18:50PM -0600, David Farning wrote:
>>>
>>> On Mon, Jan 4, 2010 at 4:55 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>>>>> Either way, while this may be a huge philosophical difference, 
>>>>> technically it should be straight forward.  Go a head and package 
>>>>> according to debian standards and expectations.  We can add a 
>>>>> couple of changes downstream for handling ALSO installs.  If and 
>>>>> when those changes prove useful, we can talk about pushing them 
>>>>> into Debian.
>>>>
>>>> What downstream hacks do you have in mind? Is it not currently 
>>>> working to install .xo bundles in Debian, or am I missing the 
>>>> point?
>>>
>>> Below is a snippet of the script to used to preinstall .xo when 
>>> constructing the Ubuntu-Sugar-Remix.  I think that SoaS does 
>>> something similar.
>>
>> Sorry if my question(s) were ambiguous: My interest (here and now) is 
>> not in actual code, but in understanding if there is something broken 
>> in the way the current Debian packages do things, or you are talking 
>> about extensions/hacks that should perhaps be adopted upstream 
>> instead - and if not, I want to understand *why* it makes sense to 
>> maintain something downstream (either Debian+Ubuntu or only Ubuntu).
>
>The only reason for maintaining it down stream would be if it is useful 
>to a set of end users yet violates Debian policy or conventions.  If 
>this fall into that case then it seems reasonable to do so.
>
>I would not consider it broken.... but it would be convenient if the 
>set of packages sacha mentioned could be installed as part of a 
>'default' sugar installation with out the activities themselves being 
>installed.
>
>Activity developer expect the APIs from that set of packages to be 
>available to them.  Yet, if an end user attempts to install a bundle 
>that depends on those API they will get an expected error unless it has 
>been installed.

I suspect that there is no problem at all here: users wanting to install 
.xo bindles need no hacks or custom scripts, but just need to install 
whatever libraries the .xo files depend on - which may be covered by a 
honey-libs-NN package or not, depending on the actual .xo's.

(please note that i've changed my mind regarding naming of that package: 
honey-NN is bad as it does _not_ provide honey, only the supporting 
libraries for (well-behaving) honey activities).


  - Jonas

-- 
* 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.alioth.debian.org/pipermail/debian-olpc-devel/attachments/20100105/069e6271/attachment-0001.pgp>