[Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging

[Peter Robinson]

On Thu, Aug 2, 2012 at 1:59 AM, Sridhar Dhanapalan
<sridhar at laptop.org.au> wrote:
> On 30 July 2012 23:26, Jerry Vonau <jvonau at shaw.ca> wrote:
>> The idea works well for users of Dextrose where OLPC-AU as a deployment
>> could omit features that are still under development and not show the
>> icon the control-panel at all. I'm not asking for anything to be
>> removed, just packaged and made available separately.
>>
>> Once the spec file is altered OOB users would state which of the applets
>> to install or substitute their own. The one rub would be having to alter
>> the sugar-desktop group definition available from fedora's repos.
>>
>> Just trying to ease the burden on some of us deployments.
>
> This feature would make maintenance of code and updates in the field
> much easier for us.

As I've said I'm happy to make improvements but I also want to make
sure that one change that helps one group of people doesn't hinder
others. Please don't see this as rejection, I'm just assessing all
possibilities and gathering other opinions.

> As a deployment, we would like the choice of which CP applets to
> include, or even make substitutions if need be. We don't want to be
> making unnecessary patches or building our own Sugar RPM just for
> this. That would in effect be a fork of Sugar and become a maintenance
> burden for us.

Yes, I agree, but in some cases, such as the network panel, it might
be that it's dependant on other code elsewhere so it might not make
sense.

> We use yum to provide automatic updates to our XOs in the field, and
> we must be mindful that large RPMs can have an impact on the school's
> Internet connection. If 400 XOs need to download a ~800KB Sugar RPM,
> that's 320MB being downloaded, potentially at the same time.

Do you have any form of proxy? A local transparent proxy would mean
400 XOs still only download 800Kb over the link. There's lots of ways
to skin a cat.

As for rpm updates I would be interested to hear how you're
distributing and pushing them out, I've had a number of queries over
the years about distribution of updates so it might be worthwhile to
document some things centrally.

Regards,
Peter