On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher 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. I am not opposed, however I think we should possibly just have people enable the 32 bit x86 repo instead of your proposal > > ## 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. the content is hardlinked so this is not an issue > * 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). Nothing stops us supporting multilib as we do today, and not supporting in it in modules > * Requires us to maintain and keep up-to-date the 32-bit container base > images. We have never made 32 bit containers, so this would be a entirely new deliverable. > > ## 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. gcc would need to be reconfigured to not be able to build 32 bit binaries on 64 bit > * 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.) given that i686 has been demoted this is a bigger issue. than it would heva been otherwise. How will apps like skype wine etc work that need to connect to X? > > ## 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? Dennis
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
