On 01/05/2017 01:26 PM, Josh Boyer wrote: > On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: >> On 01/05/2017 11:17 AM, Tom Hughes wrote: >>> On 05/01/17 16:03, Stephen Gallagher wrote: >>> >>>> For many years, Fedora has supported multilib by carrying parallel-installable >>>> libraries in /usr/lib[64]. This was necessary for a very long time in order to >>>> support 32-bit applications running on a 64-bit deployment. However, in today's >>>> new container world, there is a whole new option. >>> You may be living in a "new container world" but that doesn't mean the rest of >>> us (or our users) are. >>> >> By "new container world" I meant "a world where containers exist and can offer a >> complete 32-bit runtime" rather than a hacked-in multilib runtime. >> >>>> I'd like to propose that we consider moving away from our traditional approach >>>> to multilib in favor of recommending the use of a 32-bit container runtime when >>>> needed on a 64-bit host. >>> On the face of it it sounds like a terrible idea but perhaps I have >>> misunderstood the consequences. >>> >>> Can you explain what this would actually mean for an average software developer >>> trying to build a 32 bit program? >>> >>> Take for example my day job where I'm developing a proprietary application on a >>> Fedora workstation. Now mostly I use a 64 bit build of the software but we have >>> a few databases we support where the vendor doesn't provide 64 bit libraries so >>> I have to use a 32 bit build. >>> >>> Would this mean I had to do some special dance to enter a container environment >>> in order to work with a 32 bit build rather than just telling our build scripts >>> to use "gcc -m32" when compiling? >>> >> Building of software shouldn't be changed at all in most cases. The main >> difference would be installation/deployment. The idea would be that instead of >> the 32-bit and 64-bit runtimes being installed directly in parallel on the base >> system, they would instead be installed into effectively a chroot with its own >> completely 32-bit runtime. > You just described a fundamental change to how people would need to > build 32-bit applications locally. They don't have to install a > VM/chroot to do that today, they would in a containerized multilib > solution. I don't think it's fair to claim "Building of software > shouldn't be changed at all in most cases" with this proposal. > > Remember, not all software is built in mock or even as RPMs. End user > software developers will be impacted by the removal of existing > multilib. > > josh > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Sadly will we be hearing these same arguments 10 years from now... _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
