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 architectures. RHEL 6 supplies qemu-kvm only on x86-64. This provision lets us provide qemu-kvm on i386 and ppc64 I think. My questions: 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? Rich. -- 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. http://et.redhat.com/~rjones/virt-top _______________________________________________ epel-devel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/epel-devel-list
