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

[Jerry Vonau]

On Mon, 2012-07-30 at 10:14 +0100, Peter Robinson wrote:
> On Mon, Jul 30, 2012 at 3:43 AM, Jerry Vonau <jvonau at shaw.ca> wrote:
> > 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
> 
> The above 3 I agree with splitting out.
> 

Good some agreement.

> > Power - XO specific code
> >
> > About my Computer - XO specific code
> 
> It's not XO specific code except the serial number in Identity and
> there's no reason that can't pull the details for the other machine
> details if it's not an XO. The build is taken from the
> /boot/olpc_build file and you can put what ever you like in there. It
> also includes the license details which really shouldn't be removed.
> 

So disabling powerd, Firmware, Build, Serial Number, and Lease are not
XO specific?

> > Modem Configuration - distro specific.
> 
> It's not, it should be using the configuration from ModemManager which
> is used by all the major distros for 3G stuff.
> 

Yea they're inter-dependant, but what will differ are the plugins used
by the distro for NetworkManager.

> > Date & time - is distro specific, doesn't work work right doesn't change
> > system hence gnome is wrong.
> 
> Then it's likely a bug that should be fixed rather than just plain removed.
> 

Sugar doesn't ship gnome, and a bug has been filed. In the meantime
while in development you don't have to reinstall all of sugar to test
changes to an applet. Work the bugs out and pass upstream for inclusion
in sugar proper.

> > Network - distro specific - to be able to add features without touching
> > base sugar.
> 
> Again, uses NetworkManager like the rest of the Network code in Sugar.
> All major distros use NetworkManager and there's a lot of other code
> that needs to be changed all over the shell and toolkit to be able to
> remove NetworkManager. In 0.94+ (maybe 0.96 and we back ported it for
> 0.94 in Fedora) it uses NM 0.9 and shares configuration with gnome.
> 

No need to remove, just change packaging in the spec file. The applet
has the Server box, discard network history and radio. Getting the proxy
settings interface upstream is still on the Features list but working
here. :)


> Shouldn't the features be going upstream rather than just plain
> forking the code? Also you'd need to patch other components of sugar
> to change the network code.
> 

Not really, for example you could add functions that don't impact sugar
directly like setting of NTP servers to use without having to touch
sugar's inner workings. Call up NM applet with a button to test advanced
options where Neighbourhood View doesn't offer them like configuring a
wired usb interface, or hidden SSIDs.

The features will go upstream when excepted upstream. In the meantime
the deployment doesn't have to re-roll sugar when an update comes out if
there were no changes to the applets. Just like software updater and
switch-desktop are standalone at the moment. 

> > 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.
> 
> I agree but in the case of SoaS there's likely only one I would want to remove.
> 

Just wondering which one?

> > 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.
> 
> In some cases I agree, as documented above developing others, like
> Network, require changes in other areas of the core sugar code so IMO
> don't make much sense. I can still be convinced though, and of course
> like everything if we make one decision today doesn't mean it can't
> change down the road.
> 
> Peter

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.

Jerry