On Thu, Jan 5, 2017 at 1:31 PM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote: > > > 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. > Sadly will we be hearing these same arguments 10 years from now... I'm not suggesting we shouldn't change our multilib strategy. I'm saying we can't change it can claim that it won't impact end users. That is all. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
