This kind of strict version check at runtime smells a bit over-eager to me, but
(luckily :)) I'm not familiar enough with libdb to tell if it's incorrect.

Anyway, the error message is certainly confusing: it shouldn't matter at all
what db.h *header* is present at runtime, and it's not actually checking that.
Instead, AFAICT it's checking that the version of the shared libdb present on
the system at runtime is exactly the same that it was compiled against.

The version checking code is in ext/DB_File/version.c.  Upstream might be
interested to hear about the confusing error message and could probably provide
insight on what's the actual db version requirement.  (rt.cpan.org, distribution
 DB_File)

Anyway, I guess the quick fix would be to either really require the same version
of libdb, eg:

  Requires: db4 = %(rpm -q --qf %{VERSION} db4-devel)

...or to remove comparison of the "patch" db version components in
ext/DB_File/version.c, leaving only major and minor in.  In this case, the db4
shared lib name would suffice as the dependency as it is now.  Caveat: I don't
know if this is a strict enough version check, see above.

(Or instead of removing the patch version check, turning the != into a >= there
could be a better idea.  Same caveat as in comment 1 still applies though.)

Since we cannot run rpm query during rpmbuild, the preferred solution is to
patch ext/DB_File/version.c?

This is not urgent, but will accept into FC4 after test3 if a patch is supplied.

I don't think there are problems running such a query at build time, but
patching would be a better solution indeed if it's the right thing to do. 
Someone more familiar with db4 would have to confirm that.

On second thought, mixing repositories is unsupported and the initial report was
of rawhide during an inconsistent state.  Closing WONTFIX, unless someone is
willing to submit a concrete, simple and obviously correct way to do this.

This just bit me again.

<sarcasm>
"mixing repositories is unsupported" -- yeah, you're right, why should you go to
any effort to support the people who are willing to break their systems
regularly by keeping up-to-date with Rawhide to help find and fix bugs in
Fedora?  I mean, why take 15 minutes to add a dependency to the perl spec file
that could save your testers hours and hours of grief?  I can see how that's
just not worth it.
</sarcasm>

> Closing WONTFIX, unless someone is
> willing to submit a concrete, simple and obviously correct way to do this.

Nobody has.

What's wrong with the solution already proposed?

Requires: db4 = %(rpm -q --qf %{VERSION} db4-devel)

The only objection raised to this was "Since we cannot run rpm query during
rpmbuild," but no explanation was given for why this is so, and someone else
disputed this objection.  I just tested it and it works just fine.

Hi, sorry for the late response.

It isn't safe to query rpm inside of a spec file in Fedora. Here's why:

When the Fedora buildsystem builds a package, it builds each package inside a
new, clean, freshly generated chroot. It uses the system files to generate the
chroot, and the system files are not guaranteed to match the equivalent files
installed inside the chroot.

To put it succinctly, the rpm used to install the packages in the chroot build
environment is not guaranteed to (and in almost every case is not) the same as
the rpm inside the chroot. Thus, you have an rpm database inside the chroot
which was created with an older db4, and a rpm inside the chroot that uses a
newer db4. When rpm queries the database, you get a db4 environment mismatch,
and nothing useful comes out.

This is why we do not let people do that in Fedora.

It works fine for you, because you are far more likely to have the same rpm
which created the database when you are querying it.

With that explained, here's the workaround to solve this specific problem:

%define db4_major %(grep "DB_VERSION_MAJOR" /usr/include/db.h | cut -f3)
%define db4_minor %(grep "DB_VERSION_MINOR" /usr/include/db.h | cut -f3)
%define db4_patch %(grep "DB_VERSION_PATCH" /usr/include/db.h | cut -f3)

...

Requires: db4-devel = %{db4_major}.%{db4_minor}.%{db4_patch}

I'm committing this change to rawhide right now.

We're also contacting DB_File upstream to see if they really need this strict
version check (our suspicion is that they do not).

Thank you.

Here's the link to the upstream RT:
http://rt.cpan.org/Public/Bug/Display.html?id=30013

Fixed in rawhide, and upstream relaxed the dependency in DB_File 1.816.