On Thu, 5 Jan 2017, at 04:28 PM, Christian Schaller wrote: > 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 Doesn't sound great to me. At work I use a lot of 32-bit prebuilt toolchains for embedded devices. While I actually do often run them in a container, requiring using a container feels a bit heavy weight when most of the time I would rather not think about them as 32-bit executables - rather just executables! This is yet another case where being able to run 32 and 64 bit tools along side each other without thinking too much about it makes sense! Michael _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
