Actually, srfi-{34,35}.scm is now shipped with guile-lib which's a new
dependency of g-wrap release 1.9.9-RC1 but, not imported yet in fedora
repository, cause g-wrap has been orphaned.
However i took over the maintainance of it and will import it soon.
guile-lib has been imported in order to release g-wrap-1.9.9-RC1.

So, guile-lib shouldn't be installed yet.

Thanks for the bug report,
we will try to fix it as soon as possible.

To let you know why you have this dependency issue, I'll explain the actual 
situation about g-wrap to you.

In the g-wrap-1.9.9R1, some of the files provided by the g-wrap-1.9.6 has been 
split up into other packages. For example, guile-lib.

However, the previous fedora maintainer of g-wrap has orphaned g-wrap. That 
is, he didn't want to package it anymore for fedora and g-wrap has been 
removed from the fedora-development repository.
Reason: in F7 and development repositories, no other package requires it.
Also, some files keep on roaming from one package to another, making packaging 
guile stuffs difficult.

However Xavier and I are packaging gwave which requires g-wrap, but the latest 
version of gwave requires only g-wrap-1.9.9 which we will ask for package 
review soon.

Since, no one now owns Xavier will overtake g-wrap it now.

However like I said in F7 and development branch, no other rpm package 
requires g-wrap, I'm just curious why you need g-wrap so that we do take your 
activities into consideration for the next release.

We will post the g-wrap rpms we are working soon, so that :
* you might test them
* and eventually solve your problem.

Actually, I'm not using g-wrap anymore, but I'm still installing it together
with guile and slib on fresh installs as a result of getting used to it from
older times (I used to develop things for guile 1.6 mostly for robotics, also my
port of some guile-tools from guile 1.4 to 1.6 was included to guile rpm package
around FC4/FC5). As far as I remember, gnumeric used to have g-wrap in its
dependencies. I won't bother if it's going to be replaced by guile-lib package.

As from Fedora Core 6, Fedora is shipping guile-1.8.

If you still want to use guile-1.6, it's now named: 
* compat-guile-16
* compat-guile-16-devel
To compile your packages with guile-1.6 please read.
http://clunixchit.blogspot.com/2007/01/compiling-geda-packages-with-compat.html

There will be no replacement of g-wrap but rather,
g-wrap now requires guile-lib.

Do you need other opensource tools for robotics inside the fedora collection ? 
If yes, what are they?

That's a good question, but the answer isn't that simple. Most of this software
is badly written (with no assumption that it will be used by wide public), has
no installation scripts and in most cases is prepared to run in user's home
directory. Of course, there are some ready-to-use projects like Robocode,
however this one needs Java 1.5 so I guess Fedora maintainers won't be happy
with that.
I was using Aria software from AktivMedia for some time, but it is already
distributed as an rpm and there's no problem with adding it to living rpm-based
system. However, I don't know what are the legal issuses with adding it to the
distribution.
Totally open-source project that I'm involved with is the Player/Stage/Gazebo
suite of robotics programs. Most stable version line is 2.0.x, but it will be
soon replaced with 2.1.x line. Unfortunately, API changes are quite deep so all
surrounding infrastructure will be soon rewritten (and this takes time).
The project page is: http://playerstage.sourceforge.net
Player is the core of whole project. It is extensible by plugins, and both Stage
and Gazebo are simulation plugins (Stage - 2D simulation, Gazebo - 3D
simulation, heavily using nvidia OpenGL extensions, therefore it will be hard to
make it popular). Since Player might be considered as a kernel for some
artificial OS (with drivers, internal and external communication, threads,
access to the hardware), it has many dependencies:
- opencv/-devel (already in FC6/F7) - many Player drivers are using that for
image processing
- libraw1394/-devel and also libdc1394/-devel, libdc1394_control13 all of 1.1.0
version (due to API compatibility issues!), can be taken from
http://atrpms.net/dist/f7/libdc1394 (FireWire cameras are quite popular among
roboticists)
- gsl/-devel
- openssl/-devel
- boost/-devel
- gtk2/glib2/pango/atk/freetype2/-devel
- libgnomecanvas/-devel
- python/-devel, swig, sip/-devel
- libtool-ltdl/-devel (critical dependency!)

Optional Player software:
- festival (fortunately, player compilation does not require -devel headers as
it uses festival through TCP connections)
- wireless-tools (headers used at compile time, unfortunately, Fedora
wireless-tools does not provide headers therefore kernel ones are used which
fails at ./configure stage and therefore wireless networking features aren't usable)
- ARDev - augmented reality toolkit - http://ardev.sourceforge.net
- Pyro - Python robotics with tkinter GUI by Douglas Blank -
http://pyrorobotics.org - it uses Player as a server, unfortunately, it is
started in user's home directory and probably still uses old 1.6.x Player API.
Note that Player itself contains Python bindings, so there's no need to use Pyro
for Python robotics programming.

Stage simulator dependencies:
- Player (of course)
- gtk2/glib2/pango/atk/freetype2/-devel
- libgnomecanvas/-devel

Gazebo simulator dependencies:
- Player
- wxPython/-devel
- libxml2/-devel
- ode/-devel
- freeglut/-devel
- lib3ds-devel
- gdal/-devel
  - cfitsio/-devel
  - ogdi/-devel
  - grass/-devel

Patches for Player-2.0.4:
http://king.net.pl/playercontrib/my_patches/player-2.0.4/client_libs/libplayerc++/playerc++.h.diff
http://king.net.pl/playercontrib/my_patches/player-2.0.4/client_libs/libplayerc++/simulationproxy.cc.diff
http://king.net.pl/playercontrib/my_patches/player-2.0.4/libplayercore/configfile.cc.diff

Patches for Stage-2.0.3:
http://king.net.pl/playercontrib/my_patches/stage-2.0.3/src/stage.c.diff

3rd party client side libraries:
- Cameron Morland's library for Octave (needs octave-devel at compile time). At
first only for 1.6.x Player API, but I've rewritten it to use Player 2.0.x API
(requires patched version of player-2.0.4):
http://king.net.pl/playercontrib/octplayer2
- guileplayer: Player bindings for guile 1.6 written by me:
http://sourceforge.net/projects/guileplayer - look for guileplayer2 at downloads
, it's compatible with both Player-2.0.3 and Player-2.0.4. Cannot be compiled
with guile-1.8 :(
- java-player by Radu Bogdan Rusu - http://java-player.sourceforge.net
- lisp-player by Armin Muller - http://lisp-player.sourceforge.net

3rd party cliend-side software:
- videoplayer2 - camera viewer (playercam replacement; playercam is a client
side program shipped with player, videoplayer is much simpler which is an
advantage sometimes): http://king.net.pl/playercontrib/videoplayer/videoplayer2
- playerlibsdl - 2.0.4 API client side libraries replacement and client side
software (playerv, videoplayer) ready to recompile using them - for those who
don't want to install whole Player, just need client-side programs to connect
Player server running on remote host. It uses SDL_net/-devel instead of BSD
sockets and my own implementation of Sun's XDR serialization (based on glibc XDR
source code) and can be compiled almost everywhere including windows operating
system. Other dependencies are: gtk2/glib2/pango/atk/freetype2/-devel and
libgnomecanvas/-devel. May conflict with Player-2.0.4 globally installed on the
same host.

Regarding guile and robotics, two years ago I've written guilebots - simple
simulation extendable by plugins written in Scheme. The purpose was purely
educational: to learn Scheme and to get an idea of behavior-based robotics. It
is quite interesting, as each plugin works in separate thread so complexity of
one robot's "living function" has no impact on other robots.
It has several dependencies:
- glib/-devel 1.2
- gtk+/-devel 1.2
- gdk-pixbuf/-devel 0.22.0
- compat-guile-16/-devel (still includes my port of additional tools :])
I've compiled it (with minor changes) using glib/gtk+ 2.x, but it failed right
after start (gtk_init call fails?). I guess it's because of the way I'm using
threads.
Also I was able to compile it with no changss using guile 1.8.1, but it failed
on trying to lock a mutex. Something is wrong with threads in new guile?
Finally, I've prepared new tarball ready to compile on Fedora 7 with deps listed
above: http://ai.king.net.pl/guilebots/guilebots-20070805-fedora7.tar.gz

Fixed in updated release of g-wrap-1.9.9-4, guile-lib no need to be fix.

Also, if you have other electronic package/tools to be added to FPC, just post
on fedora-devel-list ;)