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:
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.