Fedora Desktop on XO
Peter Robinson
pbrobinson at gmail.com
Tue Jan 6 01:50:53 EST 2009
Hi Chris,
>> > I would remove the old fc9 build from the olpc_development repo (or
>> > even have one for 8.2.0 and one for 9.1.0 so they don't get mixed
>> > up). Surely it should be pulling cyrus-sasl from the Fedora repos
>> > anyway?
>>
>> I've just pushed a patch to pilgrim's joyride branch to switch the
>> baseurl that gets written out in /etc/yum.repos.d/olpc-development.repo
>> from http://xs-dev.laptop.org/~cscott/repos/dist-olpc3-devel/ to
>> http://kojipkgs.fedoraproject.org/static-repos/dist-olpc4-build-current/i386/
>>
>> (olpc3 is our 8.2/F9 repo, and olpc4 is the 9.1/F10 repo, so Joyride
>> should have been switched to write out the olpc4 baseurl when we
>> created the new repo.)
>>
>> And, after the change, we don't have depsolving problems any more!
>> Here's the list of packages to be downloaded -- the next question is
>> going to be how to avoid many of these dependencies. Perhaps instead
>> of trying the groupinstall, we should be hand-picking a smaller base
>> of GNOME packages from this list?
>
> Well its the list up to the "Installing for dependencies" that is
> explicitly requested, all the below is pulled in for deps. I'm not
> sure how pilgrim builds the list but I think if it uses kickstart like
> the other fedora build systems do you should be able to do a specific
> "-packagename" and its removed from the list.
>
> A quick look through the list..... if you remove tomboy you should
> loose all the mono deps, bluez-gnome and gnome-bluetooth should drop
> out all the bluetooth related stuff, nautilus-cd-burner and
> nautilus-sendto should drop various other non required deps (various
> CD burning stuff and pidgin etc), compiz* won't be required as I doubt
> the graphics adapter does cool whirly effects,
How did you go with this? Did you have any luck? I also realised that
if you drop gnome-user-share you'll drop all the httpd requirements.
I was going through the list of stuff at
http://wiki.laptop.org/go/Feature_roadmap/Run_Fedora_applications_on_XO
and have a few comments on the points made. Some might be obvious,
some not so much.
* Must support camera, microphone, speakers, wifi 802.11 A/B/G,
touchpad, Keyboard, USB interfaces, and SD interface.
- being based on Fedora all of the above comes as standard. I presume
with the wifi bit you mean support of the onboard wifi interface.
* Does not need to make it easy to share files between Fedora and Sugar.
- assuming its all running from the same base OS and just switching
GUIs this should be OK except for stuff stored in the journal
possibly. If its stored in the journal would it be possible to write a
gio interface for the journal ?
* Must fully support Yum.
- This would come as standard.
* Must come with nnnn applications on default install (will be
chosen and will be a very minimal set).
- this would be dependant on the choice of apps. we already have the
base of quite a few installed from the gnome side of things (totem,
abiword etc) in some cases its a matter of just adding the standard
'GUI' along with the sugar one.
* Must boot as fast as Sugar.
- in most cases its the other parts of the OS that take the time. Not
sure how you'll switch between the two but in the case of a gnome gui
it would be mostly the 'login time' difference.
* Must support upgrading the Fedora version and the Sugar version
in 9.2.0 and future releases.
- Like yum support this would be automatic :-)
* Must not keep two copies of any files or libraries. Any file
which is exactly the same on both Sugar and Fedora images should be
used by both and should not take twice the space.
- The issue here would be forked libraries. The ones that come to mind
specifically are abiword, totem, totem-pl-parser, telepathy and
GConf2-dbus. In some cases where the gnome desktop requires
evolution-data-server in other areas anyway there is suddenly very
little need to keep the forked packages around.
A gnome based desktop make some sense in the discussions as we already
package so much of it already
Cheers,
Peter
More information about the Devel
mailing list