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

[Jerry Vonau]

On Mon, 2012-07-30 at 00:20 +0100, Peter Robinson wrote:
> On Fri, Jul 27, 2012 at 4:42 PM, Daniel Drake <dsd at laptop.org> wrote:
> > On Thu, Jul 26, 2012 at 7:51 PM, Jerry Vonau <jvonau at shaw.ca> wrote:
> >> I would like to propose a feature for discussion and inclusion in the
> >> 0.98 cycle is packaging all control-panel applets as rpms. As this
> >> discussion does not impact the UI and more of a packaging issue I'm an
> >> not creating a Features page. The discussion can take place here on the
> >> mailing-list.
> >
> > This sounds like a good idea. Indeed, its not a sugar feature request,
> > its more a packaging detail.
> >
> > Peter, what do you think about splitting the cpsection extensions (in
> > /usr/share/sugar) into individual subpackages, to be selected by the
> > Sugar Desktop group but not as direct dependencies of the Sugar
> > packages? For F18+
> 
> I've had a bit more of a look at this. Any thoughts on what should be
> split out and what shouldn't. The language/keyboard obviously should
> be split out. Are there ones we should most definitely have (hence not
> split out)?

I'm aiming to have this done at the sugar packaging level, before OLPC
has releases their version. Of the 10 applets lets look at the
breakdown:

Language - agreed with

Keyboard - agreed with

Updater - patched out to use OLPC's version for microformat

Power - XO specific code

About my Computer - XO specific code

Modem Configuration - distro specific.

Date & time - is distro specific, doesn't work work right doesn't change
system hence gnome is wrong.

Network - distro specific - to be able to add features without touching
base sugar. 

Frame - To be able to add features without touching base sugar. 

About Me - only one left.

I'd say all of the applets. You now pick and choose the ones to include
at image creation time, SoaS included. The same rpm that is offered by
fedora should be the same as the one offered by OLPC.

This should ease development of new features in this area with
development not being tied to the release schedule of base sugar. One
could develop an alternate to what is offered, prove it works then pass
it upstream for inclusion in the next cycle, on a much smaller code
base.

Jerry