I'm wholeheartedly against this. I also view personally containers *just* as a thing to solve subset of real-world problems, but not a army knife for everything. IOW, enforcing users to use containers instead of multilib feature looks a bit hostile. Have other distros already done this movement? I'm almost sure we shouldn't pioneer this. IMO: multilib && Modularization efforts && containerization efforts shouldn't collide. More in-line comments ... On Thursday, January 5, 2017 11:03:50 AM CET Stephen Gallagher wrote: > ## 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. If that's a real issue, we should avoid working on hacks, and rather invent a new way to _declare_ some (sub)package is designed to be multilib, I filed this: https://pagure.io/pungi/issue/500 > * Less duplication of content in the mirror networks. That's not really duplication to me. > * 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). What's the reason to not have multilib in Base Runtime? Is that because it is hard to experiment with multilib in copr (rhbz#1393664) or what hacks are you referring to? The point of this remark is that there should be a way to minimize hacks. > * Requires us to maintain and keep up-to-date the 32-bit container base images. This would be pros, but we should probably have 32-bit container anyways.. > ## 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. .. user apps -> this looks like absolute showstopper IMO. Even though there are also third-party package providers like skype -- where I would personally appreciate we either forced them to move to container or provide x86_64 packages (or if there was really sufficient open source alternative to make them obsolete).. But I'm afraid such third party would rather drop Fedora support, which would be bad especially for us.. Pavel > * 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
