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. 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
us (or our users) are.
By "new container world" I meant "a world where containers exist and can
complete 32-bit runtime" rather than a hacked-in multilib runtime.
> I'd like to propose that we consider moving away from our
> 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.
In practical terms, this would be akin to installing it on a 32-bit VM, except
without the overhead and a separate kernel.
It gets a bit fuzzier when it has to interact with certain system services (see
the "Open Questions" for some examples).