6.4 overlaps

Paul Howarth paul at city-fan.org
Sat Feb 23 10:55:25 UTC 2013


On Thu, 21 Feb 2013 22:43:50 -0600
inode0 <inode0 at gmail.com> wrote:

> On Thu, Feb 21, 2013 at 6:24 PM, Kevin Fenzi <kevin at scrye.com> wrote:
> > I've now marked these dead.package and blocked them in epel6.
> 
> This bz has been sitting around for over 4 months now and is the only
> obvious remaining case where an epel package stomps on a base RHEL6
> package - perhaps someone can clean it up now too?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=867669
> 
> The following packages in epel currently have the same version as the
> same package in RHEL6 which can and does cause issues when the RHEL6
> package isn't installed already. New installs and dependencies pull in
> the epel versions in a "defaultish" configuration. I don't see what
> purpose they really serve being in epel so if some of them can be
> removed that would be swell too.
> 
> a2ps
> emacs-a2ps
> emacs-a2ps-el
> html2ps
> libart_lgpl
> lzop
> perl-B-Keywords
> perl-Class-Accessor
> perl-Class-Data-Inheritable
> perl-Class-Trigger
> perl-Devel-Cycle
> perl-Email-Date-Format
> perl-Exception-Class
> perl-File-Copy-Recursive
> perl-Font-AFM
> perl-HTML-Format
> perl-Locale-PO
> perl-MIME-Lite
> perl-MIME-Types
> perl-Module-Find
> perl-Net-SMTP-SSL
> perl-PadWalker
> perl-Perl-Critic
> perl-Pod-Spell
> perl-String-Format
> perl-Syntax-Highlight-Engine-Kate
> perl-Test-Memory-Cycle
> perl-Test-Perl-Critic
> perl-UNIVERSAL-can
> perl-UNIVERSAL-isa
> perl-XML-TokeParser
> perl-XML-Writer
> ruby-shadow
> scons
> xhtml2ps

Several of those perl packages are mine, dating back to the RHEL 6
beta, when we needed them for full arch support. What we did at the
time was to rebuild the exact same package as RHEL to put in EPEL. I
appreciate that that's not current policy and we'll do it differently
for EPEL-7.

I'm sure I've suggested this before but I don't see why the
epel-release package can't add a "cost" of >1000 (e.g. 1001) to the
epel repos so that identical packages would always be picked up from
RHEL in preference to EPEL.

Paul.




More information about the epel-devel-list mailing list