Bug 481427 - ENVRA of pexpect needs to be bumped to obsolete import from EPEL correct
ENVRA of pexpect needs to be bumped to obsolete import from EPEL correct
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pexpect (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Marek Grac
Depends On:
  Show dependency treegraph
Reported: 2009-01-24 11:57 EST by Robert Scheck
Modified: 2016-04-26 20:29 EDT (History)
4 users (show)

See Also:
Fixed In Version: pexpect-2.3-2.el4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-10-15 03:17:24 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 Robert Scheck 2009-01-24 11:57:32 EST
Description of problem:
The release tag (ENVRA) of the pexpect RPM package in Red Hat Enterprise Linux 
4.7 needs to get bumped from -1 to -2 in order to obsolete the EPEL package 

The current pexpect RPM package in Red Hat Enterprise Linux was pilfered/
purloined (I got pointed, that "stealing" as I used before is the wrong word 
even if it says the same) from EPEL (Extra Packages for Enterprise Linux), 
where I am/was the long time package maintainer.

The situation is now, if you were using RHEL 4.5 or 4.6 with EPEL and you've 
e.g. installed the duplicity package, the pexpect-2.3-1.el4 package dropped in
from EPEL as dependency. With RHEL 4.7, Red Hat had then decided to put the
pexpect-2.3-1.el4 package into RHEL 4.7, but without any increasing of version
number (maybe it wasn't even rebuilt?).

As "pexpect-2.3-1.el4" from EPEL and "pexpect-2.3-1.el4" from RHEL 4.7 are now
exactly the same, the package never got replaced. So I'm now expecting RHEL
customers out there, that still use the unsupported EPEL package rather the
supported RHEL package. The only way to solve this is, that Red Hat bumps the
release tag from -1 to -2 and pushs an update out to the customer.

As unluckily the regular package maintainer on Red Hat side of pexpect never
showed up on my old bug report #452762 and that guy has shown no reaction to
e-mails in the past too, I'm trying hereby via some Fedora involved Red Hat 
people to get him a clout and maybe somebody of the Red Hat guys can put him 
into a RPM packaging training. Forgetting and/or ignoring such RPM basics when
scrounging a package should never happen.

Note, that I've absolutely no problem with pilfering/purloining/scrounging one
or multiple of my RPM packages, spec files etc., but then please do it correct 
- bump release, add %changelog and stuff...otherwise you shouldn't IMHO be a 
RPM package maintainer.

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

How reproducible:
Everytime, see above.

Actual results:
pexpect-2.3-1.el4 from RHEL 4.7+ isn't able to obsolete the original and base
pexpect-2.3-1.el4 package from EPEL and the maintainer on Red Hat side takes
no action; the problem can't be solved by EPEL.

Expected results:
pexpect-2.3-2.el4 in RHEL which supersedes my original and base package from
Comment 1 Robert Scheck 2009-01-24 11:58:39 EST
Bug #481380 is the corresponding bug report for Red Hat Enterprise Linux 5.2.
Comment 2 Robert Scheck 2009-01-24 12:00:01 EST
Looks like no silent owner change did happen here as for RHEL 5.x, so adding 
RHEL 5 pexpect package maintainer on Red Hat side as well.
Comment 3 Marek Grac 2009-08-26 04:08:18 EDT
Package was removed from EPEL (as it should not be in both RHEL+EPEL, ticket #2108).
Comment 4 Marek Grac 2009-08-28 08:55:39 EDT
Patch: only release number will be increased
Comment 12 errata-xmlrpc 2009-10-15 03:17:24 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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