On 12/20/2010 01:41 PM, Kevin Fenzi wrote:
I'd like to put forth a proposal here, comments or other opinions very welcome. ;)
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.
Using ExclusiveArch or ExcludeArch? Or just let them be in multiple repos assuming that they will really and truly be the same?
- Items in other channels are fair game to ship in EPEL6.
Thoughts?
kevin
Fine by me. My concern at the moment is a multilib issue - gcc-gfortran.i686 not being present in the x86_64 repository, which causes:
Broken deps for x86_64 ---------------------------------------------------------- getdata-devel-0.6.2-1.el6.i686 requires gcc-gfortran(x86-32)
Other than dropping the %{_isa} from the Requires, not sure there is anything else we can do. But I haven't seen much comment on it though