While most desktop applications have migrated to 64 bit at this point there are still many that hasn't. Steam for instance is still 32-bit afaict. So doing a clean cutover like this feel a bit to drastic to me and I am not sure we have the market power to 'force' vendors to quickly migrate to containers. Christian ----- Original Message ----- > From: "Stephen Gallagher" <sgallagh@xxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Thursday, January 5, 2017 11:03:50 AM > Subject: Proposal: Rethink Fedora multilib support > > # 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? > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
