Proposal on what packages can be in EPEL6

[Toshio Kuratomi]

On Mon, Dec 20, 2010 at 01:41:25PM -0700, Kevin Fenzi wrote:
> 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/5Server/en )
> 
> 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? 
> 
I don't 100% like this but it seems like the best we can do with a messy
situation.  The only thought I have is we might want to modify some of this
after we see what CentOS does.  For instance, if they ship the virt stack on
x86 but do have to make modifications to make it work there we should
consider rebuilding with their packages or rebuilding with packages that
are NEVR lower than the RHEL packages but include the CentOS changes.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20101221/35446a33/attachment.sig>