On Fri, Jan 22, 2016 at 6:53 AM, Ian Malone <ibmalone@xxxxxxxxx> wrote: > On 22 January 2016 at 09:05, Paul Howarth <paul@xxxxxxxxxxxx> wrote: >> On 21/01/16 22:24, Ian Malone wrote: >>> >>> Since RHEL/CentOS 7 already does not exist in a native 32bit version I >>> do wonder what would actually be running in a hypothetical >>> mock/container/VM to build and run 32 bit systems down the road if >>> multilib went away. >> >> >> CentOS 7 does now have a 32-bit version: >> >> http://seven.centos.org/2015/10/centos-linux-7-32-bit-x86-i386-architecture-released/ >> > > While interesting to know, that is a CentOS SIG effort. If you are > using RHEL you presumably aren't supported for it, and I'm giving it > as an example of the way things are going. In any case I find this If you're using RHEL, then you'd use RHEL to build for RHEL surely. Which means you build on RHEL however it enables you to build 32-bit applications. Sure, you could use Fedora to build for RHEL, but I find that baffling in either the mock or the multilib case. There's just no sanity in expecting something built on Fedora multilib to work on RHEL except in the simplest of cases. > whole 'just build in mock' as a work around for what is basically a > packaging problem a rather weak fix. Why is multilib devel install of > libraries any more difficult than multilib install of run time > libraries? They live in the same place. If the issue is header > includes and documentation conflicting, if that's a real problem then > shouldn't it be .noarch? I wasn't suggesting to not fix the packaging bugs. I was going down a thought experiment path with Dennis' suggested dissolution of multilib to see if there were any major consequences. Aside from convenience and historical precedence, I haven't seen much. My apologies if I led you to think I was saying the current issues shouldn't be resolved. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
