On Wednesday, May 06, 2015 06:53:54 PM Stephen John Smoogen wrote:
> On 6 May 2015 at 18:21, ToddAndMargo <ToddAndMargo(a)zoho.com> wrote:
>> On 05/06/2015 09:31 AM, Stephen John Smoogen wrote:
>>> On 6 May 2015 at 00:28, ToddAndMargo <ToddAndMargo(a)zoho.com> wrote:
>>>> Hi Kevin and EPEL,
>>>> Is there any sign of EPEL 7 support for Wine 32 yet? The
>>>> lack of Wine 32 is keeping me on SL 6.6 and it is starting
>>>> to drive me nuts!
>>>> EPEL: think of the guilt you would feel if I get
>>>> stuck in an insane asylums over the lack of wine 32
>>>> support! Seriously, the guilt would haunt you to the end
>>>> of your days. Okay, maybe not, but still ...
>>> Sadly it isn't possible in EPEL. There are not enough of the i686
>>> libraries available to compile all the tools needed. It will require
>>> people actually doing the work to making an i686 CentOS or Scientific
>>> Linux but that only seems possible if the glibc/kernel/some other
>>> tools are not the same as in x86_64 and it would require people to
>>> actually do the work which no one has shown much effort in wanting to
>> Hi Steven,
>> Does this help?
>> Seems like most of the thinking has already been done.
> Not really. That works well for building it yourself and you should
> follow those instructions for your own benefit. It doesn't work in our
> build system for various reasons I can give hand-wavey answers to but
> Dennis Gilmore or another Release Engineer could answer in depth if
> you need. [And from my last asking about this.. it isn't something
> that can be fixed simply.]
a few issues, the biggest one is that koji enforces single arch in the
buildroots. so we can only build i686 in a i686 chroot. since we do not have
enough i686 content to enable building i686 its not possible that route. the
other way to try and do it would be to cross build the world so that we have
x86_64 rpms with 32 bit content in them. that would require exeptions to the
packaging guidelines, and somoene to write new specs for every package needed
and to get them through review. in the end you would have to use a non rhel
evironment and you would have say glibc32 openssl32 etc x86_64 rpms that means
a massive support burden. without Red Hat providing full 32 bit trees its
just not a realistic option to support any 32 bit builds for epel7
Any sign of Red Hat changing their ways? Or are they
just sick and tired of 32 bit?