Bug 144672
Summary: | perl needs dependency on specific libdb version | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jonathan Kamens <jik> |
Component: | perl | Assignee: | Tom "spot" Callaway <tcallawa> |
Status: | CLOSED RAWHIDE | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | jose.p.oliveira.oss, nobody+pnasrat, perl-devel, robin.norwood, scop, wtogami |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-01-02 21:12:58 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jonathan Kamens
2005-01-10 15:59:48 UTC
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. |