pexepct is in RHEL and should be dropped from EPEL

Mike McGrath mmcgrath at redhat.com
Thu Jan 22 22:11:25 UTC 2009


On Thu, 22 Jan 2009, Robert Scheck wrote:

> 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.
>

This is nice and all but EPEL is compatable with RHEL, not the other way
around.  We, unfortunately, have a one way relationship with RHEL.  They
decide what goes into RHEL, not us.  It would be nice to have more open
communcation about these things (I hope that is coming in the future) but
still, they can decide whatever they want to.

	-Mike




More information about the epel-devel-list mailing list