Overlap policy v20120615

Kevin Fenzi kevin at scrye.com
Fri Jun 15 21:29:49 UTC 2012

On Fri, 15 Jun 2012 22:28:36 +0200
Jan-Frode Myklebust <janfrode at tanso.net> wrote:

> As an enterprice RHEL customer I've always regarded having EPEL
> enabled on all our servers relatively safe. EPEL is the only external
> repository we trust.  This new policy worries me, because it seems
> like we no longer safely can have EPEL enabled on servers that
> subscribe to addons.

Yeah. I can understand that concern. 

How do you handle issues between add-ons? 
Even the base ones I see conflicting packages... do you have RHEL folks
handle that and enable them as you like, or is there some kind of
"Please dont enable foo and bar because they conflict" you look at?

> RHN-channels we currently use for RHEL6 is:
> 	updates
> 	supplementary
> 	optional
> 	rhn-tools
> 	rhevm-3
> 	jbappplatform-5
> 	sfs

I don't know off hand what is in those. 

> On the upside, the new policy seems to allow including the whole
> sfs-channel in epel, as it's only xfsdump, xfsprogs, xfsprogs-devel
> and xfsprogs-qa-devel. ..

Does that include the kernel module as well? 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20120615/6690c444/attachment.sig>

More information about the epel-devel-list mailing list