![](https://secure.gravatar.com/avatar/725af2b61adb9dbc80d9b1b9e68b6fa1.jpg?s=120&d=mm&r=g)
[Tres Seaver, 2009-11-16]
Values could be things like "libxslt", "libpng", etc..
Am I right in understanding this as informational field only ?
Yes. The primary consumers will be OS packagers, who will map them onto their own package names. As with other metadata they care about, we hope that the packagers will suggest packages to make these names "uniform" acrrss Python distributions. I imagine there will be some jockeying among them to find the "common" name for such things, which they will then need to map.
How about putting there what we (distro maintainers) can pass to ctypes.util.find_library()? It would be great if there would be another field for build dependencies, though. F.e. enchant extension required enchant headers to build enchant.so (so libenchant-dev package was required at build stage), but now it uses ctypes only and enchant.h is not needed at all. Previously I used ldd (or dpkg-shlibdeps to be exact) to get runtime dependencies from .so extension (so once I figured out the right build dependencies, runtime dependencies were generated automatically), now I use: from ctypes.util import find_library; print find_library("enchant") to generate right depenencies, but I had to read the sources to figure out what to pass to find_library. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645