Overlap policy v20120615
Richard W.M. Jones
rjones at redhat.com
Sat Jun 23 15:51:46 UTC 2012
On Fri, Jun 15, 2012 at 10:43:54AM -0600, Kevin Fenzi wrote:
> Ok, here's another attempt at an overlap policy.
> I'd like to ask folks to comment on it again, but please... I'm a
> technical person. I like technical arguments. If you don't like this
> policy, please propose an alternate one you like better and tell us
> why. Or if you like this policy ok, but changing some wording would
> make it much more acceptable, tell us that.
> ok? Here's another stab at it:
> "EPEL6 will not normally ship packages that are shipped already in the
> following RHEL channels: os, optional, lb, and ha. Any overlapping
> packages must be to provide binary packages on arches not provided by
> RHEL ( following:
> http://fedoraproject.org/wiki/EPEL:Packaging#Limited_Arch_Packages ).
> Additional channels may be added to this list, based on a criteria the
> EPEL sig has yet to decide on."
Kevin, about the provision to provide packages for other binary
RHEL 6 supplies qemu-kvm only on x86-64. This provision lets us
provide qemu-kvm on i386 and ppc64 I think.
Does it have to be the same n-v-r of qemu-kvm? (This seems like it
would be impossible in practice, so I guess the answer must be no)
Can the other arches be provided by a differently named package? (We
call it 'qemu' in Fedora)
Can the EPEL package override the x86-64 package from RHEL, eg. by
providing qemu-kvm.x86-64 with a higher n-v-r? Or should the EPEL
package ExcludeArch the RHEL packages that exist?
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
More information about the epel-devel-list