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

[Jerry Vonau]

On Thu, 2012-08-02 at 09:53 +0100, Peter Robinson wrote:
> 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 have a toggle for the wifi at a known location, a function to write a
gconf key that sugar knows about, and the ability to delete a known
sugar file. That is hardly fully integrated, while improvements that
could go upstream there is no quick means of testing without an rpm to
test with. This will open up an avenue for quicker testing, you can be
assured that the core sugar code base has not been altered while
comparing the new applet code, and is a smaller download to boot. 

In my opinion should "about my computer" gain a dependency on bitfrost's
API this would be the logical place to add the 'requires', sugar doesn't
have bitfrost as a dependency at the moment while sugar-update-control
does.

> > 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.
> 

We have no control over the network environment what so ever and need to
work within the confines of what is available.

> 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.

We have two ways of pushing out rpm updates. First is the offline method
using our One Education USB[1] tookit with some Customization Stick[2]
alterations[3]. Second is DX3's[4] sugar-client[5] to check for yum
updates in repos that we maintain.

Jerry

1.https://dev.laptop.org.au/projects/xo-au-usb/wiki/Wiki
2.http://wiki.laptop.org/go/Customization_stick_development
3.https://dev.laptop.org.au/projects/xo-au-usb/repository/revisions/master/show/dracut
4.http://wiki.sugarlabs.org/go/Dextrose/3
5.http://wiki.sugarlabs.org/go/Sugar_Server_Kit/sugar-client