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

[David Farning]

On Mon, Jan 4, 2010 at 9:19 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> 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).
>
>
That sounds good.

david