[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Overlap policy v20120615



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]