Proposal on what packages can be in EPEL6

[Kevin Fenzi]

On Tue, 21 Dec 2010 12:31:30 -0800
Toshio Kuratomi <a.badger at gmail.com> wrote:

> I don't 100% like this but it seems like the best we can do with a
> messy situation.  The only thought I have is we might want to modify
> some of this after we see what CentOS does.  For instance, if they
> ship the virt stack on x86 but do have to make modifications to make
> it work there we should consider rebuilding with their packages or
> rebuilding with packages that are NEVR lower than the RHEL packages
> but include the CentOS changes.

Yeah, sounds reasonable to me. 

On Tue, 21 Dec 2010 13:32:58 -0700
Orion Poplawski <orion at cora.nwra.com> wrote:

> Using ExclusiveArch or ExcludeArch?  Or just let them be in multiple
> repos assuming that they will really and truly be the same?

Well, there's downsides to either. I guess just adding a ExclusiveArch
isn't too much change, but it is change. Would it be bad just just
import and rebuild them exactly from the src.rpm? 

We should spell out what we want here exactly for sure. 

> 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

I don't see any other solution. We can't change the way RHEL composes
their trees. I suppose you could file a bug and ask them to ship the
32bit one in the 64bit tree, but I am pretty sure they will just say
no. 

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20101221/9303f225/attachment.sig>