pexepct is in RHEL and should be dropped from EPEL

[Jussi Lehtola]

On Fri, 2009-01-23 at 14:55 +0100, Robert Scheck wrote:
> On Fri, 23 Jan 2009, Rahul Sundaram wrote:
> > It would be good to document best practises when spec files are reused  
> > in RHEL as is going to happen repeatedly so that both sides understand  
> > what is to be done. Someone interested in not seeing things like this  
> > should volunteer.
> 
> Best practise is, if packagers would know, how packaging and ENVRA works -
> which seems not known to all packagers (independent whether Fedora or Red
> Hat at this case).
> 
> My previous e-mail explains correct, why not bumping release of ENVRA is
> broken in such a case (which also would automagically cause %changelog to
> get silent rpmlint) and why it has to be fixed by Red Hat and why we at
> EPEL can't fix or solve it completely. So if somebody does not understand
> that, he/she shouldn't be a RPM packager at all, sorry.

I agree completely.

What should be done now is an increase of the release version in RHEL
( / CentOS), in order to get all installations from EPEL to update to
the Red Hat version.

What is a completely different question, however, is what to do with the
packages in EPEL. If the release in RHEL is incremented, and the package
is updated in EPEL afterwards to a higher EVR, the RHEL version will be
replaced with the EPEL version.

As a EPEL package maintainer, branching versions for different RHEL
releases (Updates) would be a humongous task, as some components need
special tweaks to work. Also, running an old release poses a security
threat.

Overlapping packages should be removed from EPEL, once a higher EVR is
available in RHEL. We shouldn't even think about people who don't want
to update to the newest RHEL release; if they need something from EPEL,
they can compile the srpms theirself.
-- 
Jussi Lehtola <jussi.lehtola at iki.fi>