[Debian-olpc-devel] Bug#563436: sugar-0.88: sugar depends on python-numpy and python-pygames
Jonas Smedegaard
dr at jones.dk
Tue Jan 5 03:19:22 UTC 2010
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>
More information about the Debian-olpc-devel
mailing list