On Thu, 22 Jan 2009, David Juran wrote: > Since the version of the packages really is the same in both EPEL and > 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. Greetings, Robert
Attachment:
pgpscGc3XGVi2.pgp
Description: PGP signature