From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
There seems to be some inconsistancy in the way RPM is handling version
comparison wrt promoting the epoch of install and build dependancies, vs when it
is checking for conflicts on install or dependancies on package removal.  For
the former case, the epoch is not promoted, and in the latter case, it is.  My
understanding is that in rpm 4.1, if there is no epoch on the dependency, then
it is assumed to be == 0 (no epoch promotion).  However, install dependencies
and build prereqs still promote the epoch.

The following spec file demonstrates this for a build dependancy:

<snip>
Summary: Test for epoch comparison.
Name: foo
Version: 1.0
Release: 0
Epoch: 0
BuildArch: noarch
License: Whaever you damn well want.
Group: Useless Stuff
Packager: Joe Mama, Inc.
BuildRoot: /var/tmp/foo-tmp
BuildPrereq: make > 3.79.1-14

%description

This RPM is useless.  Do not use it.  Just walk away.

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT/tmp
touch $RPM_BUILD_ROOT/tmp/sadlfkj.txt

%files
/tmp/sadlfkj.txt
</snip>

run the following command (which will fail the BuildPrereq check):
rpmbuild -vv -bs foo.spec

and notice the following in the output:
D: rpmdsCompare: makeD: The "B" dependency needs an epoch (assuming same epoch
as "A")
       A = "make = 1:3.79.1-14"        B = "make > 3.79.1-14"

The nopromote member of the "B" rpmds structure is not set to 1, so the epoch is
promoted.

It seems that when the add/remove elements are added to the transaction set,
addTE is called (through a few other functions) to do the dirty work of
assembling the element based on the bits of information in the header.  In this
function, rpmdsNew is called a bunch of times starting around line 115 to build
dep sets for the requires, conflicts, etc.. rpmdsNew creates the dep set with
nopromote == 0.  addTE makes no attempt to call rpmdsSetNoPromote() on the newly
created set.  More on that in a second.

Later on in the chain of events of an install, remove, or a build (which seems
to be taken as a special case of install for the purpose of BuildPrereq
checking), rpmtsCheck() is called against the fully assembled transaction.  As
it iterates through the elements, it behaves differently based on whether it is
an add or remove.  For removes, a call to checkDependentPackages() is made,
which in turn calls checkPackageSet().  For conflict checking on install, a call
to checkDependentConflicts() is made which also calls checkPackageSet().
checkPackageSet() calls rpmdsSetNoPromote() before calling checkPackageDeps() -
sort of, see below.  For _dependancy_ checking on install (or build prereq), it
goes directly to checkPackageDeps() and given the paragraph above, there is
never a chance to set the nopromote flag on the requires dep set before falling
through to rpmdsCompare (through another function or two).

I say checkPackageSet() sort of sets the flag because of this code in depends.c,
line 697 - 700:

       requires = rpmdsNew(h, RPMTAG_REQUIRENAME, scareMem);
       (void) rpmdsSetNoPromote(requires, _rpmds_nopromote);
       conflicts = rpmdsNew(h, RPMTAG_CONFLICTNAME, scareMem);
       (void) rpmdsSetNoPromote(requires, _rpmds_nopromote);

Seems to be a copy/paste error, the requires dep set has its flag set twice.

Is this context-sensitive behavior intentional?

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
See above description.

Additional info: