Re: [Announce] RPM Fusion for EL is restored - EL7 support started

Hi, On 27/01/2017 09:53, Simone Caronni wrote: > Hello, > > On Thu, Jan 26, 2017 at 10:25 AM, Nicolas Chauvet <kwizart(a)gmail.com > <mailto:kwizart@gmail.com>> wrote: > > For the record EL6 repo is provided as i686 and x86_64 whereas EL7 is > only provided as x86_64 at this time. This lead to an issue with > multilib packages in our infra (same as EPEL). So here is the possible > workaround: > If there is no specific arched dependencies (either binary only or > because of limited BR) > The best way is to build the same package on el6, I will also tag the > build on el7, so both i686 and x86_64 build from el6 will be available > on el7. > This is what I expect to use for libtxc_dxtn (and steam eventually). > > > There was a discussion to introduce an i686 target for EPEL 7, but > unfortunately there was no progress on that. Maybe last weekend Fosdem got things moving forward again for 32 bits EPEL 7 ? > Would it be possible to consider the i686 target in EL7 using the > alternative architectures of CentOS in RPMFusion? > > This of course would make things diverge a bit from EPEL, where there is > no 32 bit target, and some packages would actually stay in EPEL in their > 64 bit form. > > Tree is here: http://mirror.centos.org/altarch/7/ > How much of 32 bits EPEL 7 do we need ? Is steam streaming really that important ? Or in other words, can we start with just CentOS 32 bits and add EPEL 32 bits only when it comes to light ? I guess I can probably find out on my own with a custom mock conf. I'm wondering about the buildsys-build group though, as this is provided by EPEL iirc, and I'm not sure how to handle that. So far, there has only been 3 packages that I couldn't build for EL7 because of them being 32 bits only. Namely, that is steam, zsnes and unace. There are probably more, but I'll give at least these 3 and libtxc_dxtn a try, if I get a working mock setup.