Hello, as you can see in downstream bug:
http://bugs.gentoo.org/show_bug.cgi?id=344231

We are trying for a long time to try to solve the problem of python-finding code being really really slow on some packages (gnome-python-extras, planner...), and we would like to find an way to fix it in a way that would be upstreamable for all that cases.

Some days ago, I saw you fixed the code in gnome-python-extras:
http://git.gnome.org/browse/gnome-python-extras/commit/?id=77cca7ce35bfb4f6bc283672dc295c2bb82a3b58

But another problem appeared:
http://bugs.gentoo.org/show_bug.cgi?id=344231#c11

"It will cause new problems:
- Python doesn't install python.pc, so AC_MSG_ERROR([Can't find python.pc])
will
  be run.
- Only Python 2.7 and >=3.1 install python-${Python_version}.pc
  (e.g. python-2.7.pc, python-3.1.pc, python-3.2.pc), so using of
  python-$PYTHON_VERSION in pkg-config calls in acinclude.m4 would still break
  support for Python <=2.6."

From that comment to the end, you can see the reasoning of we don't suppling python.pc and providing python-2.7.pc instead.

A solution for this could be the following that we would like to see upstreamed:
http://bugs.gentoo.org/show_bug.cgi?id=344231#c19
"(In reply to comment #18)
> Is this situation "normal"?

Yes.

> I mean, looks like we are the only distribution having this problem...
> or upstream looks to think python.pc should be present on most of systems.

python-$(VERSION).pc is always installed by Makefile of Python 2.7 and >=3.1,
while an additional symlink might be created only when "bininstall" or
"install" target is used. Ebuilds use "altinstall" target to decrease chance of
collisions between slots. Other distributions might not support having multiple
Python versions installed parallelly.

Please convince upstream to use the following code in acinclude.m4:

if pkg-config --exists python-$PYTHON_VERSION; then
  python_ldflags=`pkg-config --libs python-$PYTHON_VERSION`
else
  python_ldflags="-lpython$PYTHON_VERSION"
fi"

Thanks a lot for your help