Proposal on what packages can be in EPEL6

[Kevin Fenzi]

I'd like to put forth a proposal here, comments or other opinions very
welcome. ;) 

In EPEL4/5 we have a policy of: "EPEL won't ship anything that is in
the Advanced Platform set of packages". This is easy to check, as all
these have src.rpms on mirrors. This includes: 

JBEAP
JBEWS
JBWFK
os
RHCERT
RHDirServ
RHDOCS
RHEIPA
RHEMRG
RHHC
RHNPROXY
RHNSAT
RHNTOOLS
RHUI
RHWAS
SJIS

(see:
http://mirrors.tummy.com/pub/ftp.redhat.com/pub/redhat/linux/enterprise/5... )

For EPEL6, we can't do this as their is no Advanced Platform, and the
secondary channels don't exist as src.rpms. We have: 

6Server
6ComputeNode
6Client
6Workstation

and all the src.rpms in a single dir under those. 

Additionally we have the following complications: 

* Some packages only have binary rpms shipped for some arches. Ie, the
  entire virt stack is x86_64. There's no client/workstation stuff in
  ppc64. There's no java in ppc64. 

* Some packages only have subpackages shipped in some arches (ie,
  pacemaker-cts and pacemaker-docs are shipped in server-optional, but
  the main pacemaker binary rpm is only in the HighAvailability
  channel. 

I would like to propose the following: 

EPEL6 will not ship any packages that have src.rpms on public mirrors
under 6* directories with the following exception: If the binary rpm
is only shipped in some arches in RHEL, EPEL may ship that exact same
version (note that EPEL maintainer must keep up exactly with the RHEL
src.rpm).

So, this would leave us with: 

* someone could maintain java in EPEL and build the exact src.rpm
  version. If it took mods to work, I would say we should just not do
  so and excludearch our java stuff. 

* folks could push packages that are x86_64 only into epel, but should
  keep them exactly the same as the rhel src.rpm. 

* Items in other channels are fair game to ship in EPEL6. 

Thoughts? 

kevin