I put together a package for igraph-0.4.5 and python bindings.
Unfortunately, the upstream is a bit messed up. The python package is
called exactly the same name (the original C is called ipython-0.4.5 and so
is the python package).
The upstream python package included it's own copy of the c code. I fixed
that problem so the python package would use the installed ipython c devel
package.
I'm guessing that the messed-up upstream is not quite as messed up as this
description, and that actually everything is called "igraph-0.4.5" and
nothing is called "ipython".
Only 1 little problem.
I renamed the python source to python-igraph-{version}.tar.gz. I did:
%setup -q -n igraph-%{version}
Now it builds fine, but:
sudo rpm -U ~/RPM/RPMS/x86_64/python-igraph-*
file /usr/src/debug/igraph-0.4.5/src/error.c from install of
python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from package
The fact that this file exists in python-igraph-debuginfo suggests that you
did not really manage to get rid of the included copy of the C code. If it
didn't compile its own copy, wouldn't it only refer to the C headers
installed by the igraph-devel package and not have any of its own?
igraph-debuginfo-0.4.5-1.fc8.x86_64
file /usr/src/debug/igraph-0.4.5/src/error.h from install of
python-igraph-debuginfo-0.4.5-1.fc8.x86_64 conflicts with file from package
igraph-debuginfo-0.4.5-1.fc8.x86_64
Any ideas how to fix this?
It is an issue with the debuginfo-generation setup that /usr/src/debug/FOO
is used by all packages that unpacked their sources into %{_builddir}/FOO.
But that is a complex can of worms I'd rather not get into just now. In
your case it seems that this limitation has probably actually been a boon
in catching for you something you didn't intend to be trying.
Thanks,
Roland