On Saturday, December 24, 2011 12:14:56 AM Claudio Freire wrote:
On Fri, Dec 23, 2011 at 9:59 PM, David Haller email@example.com wrote:
I've packaged _a lot_ of packages (a couple of hundred, most for my ex-SUSE 6.2 over 10 years (ISTR >>500 RPMs of packages by me installed), from small to quite a bunch like most of gnome). Usually, there's _very_ little you need to explicitly have in Requires that is not picked up automatically by "AutoReqProv" or via a require of the corresponding -devel packages (which you need to have in BuildRequires). And most if not all (well it should be all) configure-scripts (and alike) will check for those executables to be available for build, and so they'll get pulled into the Build and usually picked up as a Require for the Package.
Then you've never packaged python apps. You don't need any -devel stuff on python, you only need python itself to generate bytecode.
It's also the case when there's any service you connect to by IPC, like dbus, X.org, etc...
And no, libX is *not* X.org
Some applications and libraries will also load libraries at runtime via libdl, instead of linktime. I ran into a situation the other day, in fact, where an application written in C with GTK libs had SVG icons. The application would not actually run without librsvg installed, and AutoReqProv didn't pick up the dependency, since it wasn't specified to the linker and thus not in the output of ldd. I had to add an explicit Requires tag for it.
Languages like Python, Perl, and Ruby will, of course, load their libraries at runtime, but automatically detecting them is problematic. There is a script in rpm that picks up Perl dependencies pretty well, but such a thing would be difficult for Python, since it supports conditional imports, and you often see stuff like this:
try: import somelib except ImportError: import someotherlib as somelib
It's impossible to tell which one should be required for an environment without some curated list of library names and Python versions. ElementTree is a prime example of this. It was brought into the Python standard lib in 2.5 and renamed to xml.etree.
So AutoReqProv is not perfect, and it never will be. We need to be mindful of this, too. It's easy to miss one if you only test a package on a "kitchen sink" desktop install. I would not have found that librsvg dependency if I had tested the application on my desktop.