On Mon, Jan 4, 2010 at 9:19 PM, Jonas Smedegaard <d...@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 <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). > > That sounds good.
david -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
