Bug 962935 - confusing usage of epoch in spacewalk-backend package
confusing usage of epoch in spacewalk-backend package
Status: CLOSED NOTABUG
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
560
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Jan Pazdziora
Red Hat Satellite QA List
:
Depends On:
Blocks: sat560-triage
  Show dependency treegraph
 
Reported: 2013-05-14 15:27 EDT by Jan Hutař
Modified: 2013-05-15 01:51 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-15 01:51:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Hutař 2013-05-14 15:27:30 EDT
Description of problem:
spacewalk-backend package "provides" numerous versioned provides like "rhns = 1:1.7.38-45.el6sat" (including epoch), but package itself do not have epoch set (to "1").


Version-Release number of selected component (if applicable):
spacewalk-backend-1.7.38-45.el6sat.noarch.rpm


How reproducible:
always


Steps to Reproduce:
$ rpm -qp --qf="%{EPOCH}\n" spacewalk-backend-1.7.38-45.el6sat.noarch.rpm
(none)
$ rpm -qp --provides spacewalk-backend-1.7.38-45.el6sat.noarch.rpm | grep '= [0-9]\+:'
rhns = 1:1.7.38-45.el6sat
rhns-common = 1:1.7.38-45.el6sat
spacewalk-backend-upload-server = 1:1.7.38-45.el6sat


Actual results:
See above. IMO package should either define "epoch = 1", or provide versioned provides without epoch specified. In case this is expected and wanted state, please close this bug.


Expected results:
Packages epoch ane epoch in versioned provide should match.
Comment 2 Jan Pazdziora 2013-05-15 01:51:16 EDT
(In reply to comment #0)
> Description of problem:
> spacewalk-backend package "provides" numerous versioned provides like "rhns
> = 1:1.7.38-45.el6sat" (including epoch), but package itself do not have
> epoch set (to "1").

That's exactly expected. The spacewalk* packages have replaced the rhns* packages. The spacewalk* packages versioning started from 0.1 while rhns* were at 5.2 or similar.

Thus, saying that spacewalk* in epoch 0 provides rhns* in epoch 1 is actually correct, and it ensures that upon upgrade, rhns* packages get removed.

> Actual results:
> See above. IMO package should either define "epoch = 1", or provide
> versioned provides without epoch specified. In case this is expected and
> wanted state, please close this bug.
> 
> Expected results:
> Packages epoch ane epoch in versioned provide should match.

No. spacewalk != rhns.

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