Bug 111092 - Dependency failure when provider has epoch and requirer has not
Dependency failure when provider has epoch and requirer has not
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-27 07:19 EST by Julian Blake
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-30 09:46:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
provides-epoch.spec (717 bytes, text/plain)
2003-11-27 07:25 EST, Julian Blake
no flags Details
requires-epoch.spec (749 bytes, text/plain)
2003-11-27 07:26 EST, Julian Blake
no flags Details
requires-noepoch.spec (889 bytes, text/plain)
2003-11-27 07:27 EST, Julian Blake
no flags Details

  None (edit)
Description Julian Blake 2003-11-27 07:19:54 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031003

Description of problem:
When a package provides an explicit epoch, and another package
requires the provider's package version with epoch unspecified, the
dependency check fails.

According to /usr/share/doc/rpm-4.2.1/dependencies, an unspecified
epoch in a Requires line should match any provided epoch. 

I will submit spec files for three test packages which demonstrate 
the dependency treatment of a package which provides an epoch:

provides-epoch-1.4.1-17.i386.rpm
which provides provides-epoch-37:1.4.1-17
where 37 is the epoch

requires-epoch-1.4.2_01-2.cern.i386.rpm
which requires provides-epoch = 37:1.4.1

requires-noepoch-1.4.2_01-2.cern.i386.rpm
which requires provides-epoch = 1.4.1


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

How reproducible:
Always

Steps to Reproduce:
1. Copy provides-epoch.spec, requires-epoch.spec and
requires-noepoch.spec into .../rpm/SPECS/.
2. Create packages:
cd .../rpm/SPECS
rpmbuild -ba provides-epoch.spec
rpmbuild -ba requires-epoch.spec
rpmbuild -ba requires-noepoch.spec
3. Install packages (as root):
cd .../rpm/RPMS/i386
rpm -iv provides-epoch-*.i386.rpm
rpm -iv requires-epoch-*.i386.rpm
rpm -iv requires-noepoch-*.i386.rpm

Actual Results:  The first and second packages are installed. 
Installation of the third package fails with:

error: Failed dependencies:
  provides-epoch = 1.4.1 is needed by requires-noepoch-1.4.2_01-2.cern

Expected Results:  All three packages should have been installed.

Additional info:  None.
Comment 1 Julian Blake 2003-11-27 07:25:08 EST
Created attachment 96223 [details]
provides-epoch.spec
Comment 2 Julian Blake 2003-11-27 07:26:24 EST
Created attachment 96224 [details]
requires-epoch.spec
Comment 3 Julian Blake 2003-11-27 07:27:28 EST
Created attachment 96225 [details]
requires-noepoch.spec
Comment 4 Michael Young 2003-11-27 17:21:26 EST
Not specifying an epoch is broken behaviour. RHL 9 complained about
it, and I believe Fedora treats no epoch as epoch=0, so I believe this
is not a bug.
Comment 5 Julian Blake 2003-12-01 04:30:15 EST
Here is the relevant paragraph in the RPM documentation file
/usr/share/doc/rpm-4.2.1/dependencies:

"The epoch (if present) is a monotonically inceasing integer, neither
the version or the release can contain the '-' hyphen character, and
the dependency parser does not permit white space within a definition.
 Unspecified epoch and releases are assumed to be zero, and are
interpreted as "providing all" or "requiring any" value."

It is the second sentence that makes me believe than an unspecified
epoch in a Requires line should match any provided epoch.  I feel that
the behaviour described in this sentence is logical.  Do you want to
change the Requires line in every dependent package, at the moment
when you are forced to introduce, or to change, an epoch in a
providing package?

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