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.
Regards,
Xavier