On Thu, Jan 5, 2017 at 1:31 PM, Daniel J Walsh <[email protected]> wrote: > > > On 01/05/2017 01:26 PM, Josh Boyer wrote: >> On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher <[email protected]> >> 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 -- [email protected] To unsubscribe send an email to [email protected]
