On Thu, 22 Jan 2009, David Juran wrote:
Since the version of the packages really is the same in both EPEL
RHEL (pyexpect-2.3-1) I guess the proper thing to do would be to bump
the release number in RHEL. Or possibly the other way around, by
downgrading the EPEL versions to pyexpect-2.3-0.5...
Well, I think the way how the package was stolen in EPEL and imported into
RHEL was done a way too silent and thus wrong. If Jim would have come up to
me as pexpect maintainer, we could have clarified that before and thus we
could have avoid the equivalent release number thing we now have. But does
Jim really exist? He didn't yet show up at this e-mails and didn't show any
reaction to the bug report...
Currently, it is not really possible to push an older version into the EPEL
repositiories without manual work, as the scripts allow only newer things -
Dennis, am I correct? I don't know, whether it's more easy for Red Hat to
cause a release number bump for pexpect.
As this mistake was caused by Red Hat, I don't see a good reason, why EPEL
shall fix this and take care of it. IMHO a good package maintainer does
such things and has a careful look around before acting, especially if the
package is stolen (IIRC even the %changelog wasn't changed) - the Red Hat
guy didn't do that until now.