Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 50524 - rpmdepCheck() doesn't satisfy dependencies correctly
rpmdepCheck() doesn't satisfy dependencies correctly
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-07-31 17:05 EDT by wadim
Modified: 2007-04-18 12:35 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-31 17:05:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description wadim 2001-07-31 17:05:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.14-14 i686)

Description of problem:
Description of a situation(just for example): package first-1.0-1.i386.rpm
requires lib.so.1, package second-1.0-1.i386.rpm provides lib.so.1. 
headers of those packages the result I get is equal to "".  When the
function rpmdepCheck() is called which must find out that package
second-1.0-1.i386.rpm is needed for package first-1.0-1.i386.rpm, it
finally gets into function rangeMatchesDepFlags(). This function has
 if (!(reqFlags & RPMSENSE_SENSEMASK) || !reqEVR || !strlen(reqEVR))
	return 1;
As require version is equal to "",  strlen(reqEVR) == 0, function returns
1, what means that dependency for package is satisfied by rpm-database what
is not true.

How reproducible:

Steps to Reproduce:
1.Create two packages, one of which requires that, what another provides 
2.Generate hdlist
3.Write a program which uses rpmdepCheck()


Additional info:
Comment 1 Jeff Johnson 2001-07-31 20:59:55 EDT
Yup, this is exactly the way it's supposed to work.

Originally, rpm had not versions on Provides: and versions were
optional on Requires:. This is reflected in the code by the tests
for both a NULL pointer (i.e. tag is missing), as well as for the empty
string "" (i.e. no value for this element).

The semantics in that case is to interpret as Provides" all versions,
and or Requires: any version. The return of 1 is exactly correct, since
rangeMatchesDepFlags() is never called unless the name was in the database,
and the existince of the name is exactly the same as Provides: all versions or
Requires: any version.

Note You need to log in before you can comment on or make changes to this bug.