[Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
jvonau at shaw.ca
Sun Jul 29 22:43:17 EDT 2012
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
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
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
More information about the Devel