On 21 January 2016 at 15:15, Josh Boyer <jwbo...@fedoraproject.org> wrote: > On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone <ibmal...@gmail.com> wrote: >> On 21 January 2016 at 14:25, Dennis Gilmore <den...@ausil.us> wrote: >> >>> >>> However I really think we need to sit down and rethink multilib. I would >>> like >>> to start by changing the multilib method to runtime. So you only get runtime >>> libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building >>> you >>> should just use mock, docker, systemd-nspawn or something else. It would >>> mean >>> we need to make and ship a i386 docker base image if we say use docker. >>> >>> We have dropped most multilib support already. Today s390x has multilib with >>> s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, >>> we >>> are working to drop s390 which will leave x86_64 standing all alone. Given >>> changes in technologies since x86_64 first became a thing I think we sit >>> back >>> and reevaluate the idea of multilib. Maybe there is better ways to achieve >>> what we want today >> >> Successfully build and run 20+ year old programs without having to >> completely rewrite them would be one of the things I want today. In >> fact it's one of the things I was doing earlier this week. > > Is there a reason that would not work in mock? >
It would, it would require installing the entire development system in mock though, and shifting data in and out is more awkward than working directly on it. Additionally, notice the: >>> Given >>> changes in technologies since x86_64 first became a thing I think we sit >>> back >>> and reevaluate the idea of multilib. Maybe there is better ways to achieve >>> what we want today" 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. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
