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

[David Farning]

The difference is that they expect to be able to install bundles via
install_activity_bundle.  From a technical POV the issue seems similar
to how how Debian handles mozilla add ons.  There are instances where
users will want the ability to use and install addons, without being
limited by their underlying distribution choice.

The solution seem to be to create a meta package which (1) pulls in
the dependencies sacha mentioned and (2) recommends a collection of
activities.  If a user/deployer prefers to install activities via
install_activity_bundle they can install the meta package containing
the dependencies without the activities themselves.  Then they can
install things via ASLO.

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.

david

On Sun, Jan 3, 2010 at 8:55 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> On Sun, Jan 03, 2010 at 06:51:49PM -0600, David Farning wrote:
>>
>> On Sun, Jan 3, 2010 at 2:17 PM, Jonas Smedegaard <dr at jones.dk> wrote:
>>>
>>> On Sun, Jan 03, 2010 at 01:24:45PM +0100, Sascha Silbe wrote:
>>>>
>>>> On Sun, Jan 03, 2010 at 12:58:34PM +0100, Tomeu Vizoso wrote:
>>>>
>>>>> My understanding was that Jonas believes that software should be
>>>>> deployed by the distro and not by developers (by using mechanisms such
>>>>> as .xo bundles). From that POV sugar-platform is not needed.
>>>>
>>>> I don't think it should be an either-or decision. In fact it cannot be;
>>>> there's no way Debian could ship _every_ activity.
>>>> Sugar Platform is intended as a base line for _all_ activities, esp. all
>>>> the random "small" ones.
>>>> I guess Jonas was talking about Fructose activities, but will let him
>>>> speak for himself. :)
>>>
>>> User A installs the upcoming Debian Squeeze from a DVD onto his laptop
>>> deep
>>> in the jungle with only expensive satellite link to the outside world, so
>>> will only install "main" packages, not "contrib" ones that depends on
>>> software not released with Debian (packages in "non-free" are hosted
>>> using
>>> Debian infrastructure but not included with the final distribution
>>> releases).  User A will install sucrose-0.88 but not honey-0.88.
>>>
>>> User B installs a future Skolelinux consisting on Debian packages but
>>> unlike
>>> Debian also including a few "non-free" packages - notably Etoys.  User B
>>> will install debian-edu-sugar which pulls in both sucrose-0.88 and
>>> honey-0.88, and perhaps also pulls a few popular .xo bundles if reachable
>>> at
>>> install time.
>>>
>>> User C installs some future Ubuntu which includes Sugar packaged as in
>>> Debian except for a few tweaks: a splash screen is hacked in at startup
>>> time, and sucrose-0.88 is made to depend on honey-0.88 as the many names
>>> are
>>> considered user-unfriendly by Ubuntu Sugar developers. ;-)
>>>
>>> User D wants to develop Sugar activities for Latin America, so installs
>>> Debian unstable and the sugar-dev package.
>>>
>>>
>>> Does that make sense?
>>>
>>> Did I miss some obvious use case?
>>
>> Two missing use cases are:
>>
>> School A installs a base Sugar on 100,00 machines and would like
>> teachers and students to be able to install locally written activities
>> bundles.  I believe skolelinux has 10s of millions of users around the
>> world.
>>
>> Company A wants to sell machines preloaded with a base Sugar and
>> expects users and schools to be able to install additional activities.
>
> Are packaging needs of those any different from the other use cases?
>
>
> Regards,
>
>  - Jonas
>
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJLQViLAAoJECx8MUbBoAEhz4UQAI+HH/KRgbBtSL0K4mYNruU9
> 1Qd+ga6a0z3Ij1tFhD2AyF4EGCcQU+oIC7nxDrz9/j+1dT+Vo97K6nZ+s55LgpSI
> NDqEa4biLRf+epjb9TDEFWB4BgE/GMgMU2mRlSc3acfiqe3sNPe13PyPNncG+EV4
> 556GxfAacSrpJLos394INbIrRwwso9p5YEEKFuA2mfKSolJxEhB9ccCF88qH+dfy
> fb4jJRhV6deKJDs7pDQzt/Z7zv73KqF50QVjCb4U2O3ZqbLUgW/9uTxM92cpoGgT
> t48oz64Fq7favuVVvCMkwprYp0qPe480Z1ULEebZmxBjboONe0MYpKepOJ+dJLlX
> PfQqPNTthd5ZroAceJ1oM+IrGstEnivbVRqdtHMRC3DWi1ZY7zpU4QTOaCQe45Ob
> hb4qbrVfWosGjB0HU+npOQ/KRg3t+PcVCrC5WBD/tQ6/vvdB8AlJYQ3c96nMCTaP
> +y++Fm8n3rQ9RueDhnH5JK+PuE8qkmDJ31ZdECiWpkeqSLFja0Q3hONihgexa1oF
> g3fNCk6FnSiMZOtLAYiAGsmXp6OxfbhkdnP40V8VkxGwKZvMtPtgqjFi+avJKfwl
> HNXXz5hG8Qp3AxzMMyEM3bFYqADVuUm48EYyhjCKSQBkCKfrfnOAiP75Duci9Kf/
> e3a+RxIRoW1+ci8J7jp6
> =pnUO
> -----END PGP SIGNATURE-----
>
>