On Thursday, January 5, 2017, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
# Overview
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.
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.
## Advantages
* Simplification of build-tree creation. We wouldn't have to maintain the lists
and hacks that are required to make sure that multilib packages land in the
correct repositories.
* Less duplication of content in the mirror networks.
* It will be simpler to create module content without having to reimplement all
the multilib hacks of above. This is directly relevant to the Base Runtime
module, whose prototype is today intentionally limited to the primary
architecture (no multilib).
* Requires us to maintain and keep up-to-date the 32-bit container base images.
## Disadvantages
* If we eliminate multilib entirely, all applications that use 32-bit libs will
have to either install a 32-bit host OS or install into a container. This may be
a difficult transition for some users.
* Mitigation: develop and maintain tools to ease this transition.
* It is unlikely that any clean upgrade path would exist. (We could make it
*technically* possible, but likely not without breaking 32-bit software not
installed by RPM.
* Requires us to maintain and keep up-to-date the 32-bit container base images.
(Yes, this is both an advantage and disadvantage.)
## Open Questions (non-exhaustive):
* Can SSSD and systemd's 32-bit name-service modules work from within a
container, talking to their host's service? Without that, 32-bit containers
won't be able to resolve users, groups or hostnames.
* Can we have 32-bit containers communicate with other local system APIs such as
D-BUS on the host?
* Do we need to care about 32-bit GUI applications on a 64-bit system? Should we
decide that flatpak is the official answer for such cases?
This proposal is more or less "let's make life a bit easier for us in expense of our users". Your proposal shifts the hacks to the users.
There are still a lot of 32bit software out there. In stead of having it just work you are asking users to fiddle around with hacks / jumping through hoops.
So your proposal would cause way more harm than good.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
