OLPC-Update + RPMs WAS:Re: OLPC XO Opera browser as Sugar activity

[david at lang.hm]

On Mon, 30 Jun 2008, Erik Garrison wrote:

> On Fri, Jun 27, 2008 at 01:24:36PM -0700, david at lang.hm wrote:
>> On Fri, 27 Jun 2008, Erik Garrison wrote:
>>> What functionality do we certainly lose by using a package management
>>> system as our default software distribution system?
>>
>> it's not that we loose functionality by using a package-based approach,
>> it's that we increase complexity and eat up scarce development resources.
>> You see the fact that this may work better with custom packages as a big
>> advantage, I think that people who do custom packages can deal with the
>> complexities themselves, and that they are very much the exception rather
>> then the rule. by far the most common situation is, and is going to
>> continue to be, the case where the laptops are running a standard image
>> with no additional packages (note that this 'standard image' may be
>> defined by the country, not OLPC, and therefor may contain some packages
>> not in the OLPC image). it's only a small subset of the G1G1 and
>> development machines that will have custom packages on them.
>
> I agree that a package-based approach increases the complexity of our
> software distribution processes.  I observe, as you do, that we are
> already managing a complex deployment environment in which most
> large-scale deployments have their own customizations.  Individual
> deployments have specific needs.  We offer them monolithic images and
> also assistance in creating deployment-specific images.  This
> deployment-by-deployment effort increases almost linearly with the
> number of large deployments that we engage.  I suggest that a more
> sophisticated packaging system becomes useful as the effort expended on
> custom image creation reaches a certain level.  It is not clear what
> that level is, but I doubt it lies at a scale of deployment much greater
> than where we currently stand.

how many different deployment builds do you think are being supported at 
this time? I think it's still in the single digits.

I also think that before the complexity of things gets to the point where 
it's better to deploy to the laptops in a package-based system the number 
of builds directly supported by OLPC probably needs to get in the 30-40 
range (or if they are indirectly supported, probably in the 100+ range)

remember that for downstream customizers, OLPC is able to provide their 
development image (complete with the upstream package management tools in 
place, and the scripts to strip them out), so that those downstream 
customizers are able to take full advantage of the package based tools for 
creating their customized images that can then be published via the 
existing snapshot based infrastructure.

the disagreement here is over the question of if OLPC should be supporting 
the end-user customizing the laptop (other then by installing activities). 
those who think that this should be happening see an obvious need for 
package-based tools, those who think that this should not be happening 
(that the customizations are at the country level or so) see much less of 
a need to drop down to the package level for OS management.

David Lang