On Mon, Jan 04, 2010 at 06:19:57PM -0600, David Farning wrote:
On Mon, Jan 4, 2010 at 2:02 PM, Jonas Smedegaard <d...@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 <d...@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
signature.asc
Description: Digital signature
