On 01/05/2017 11:03 AM, 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. >
So, this thread provided a lot of feedback. I had anticipated that the suggestion would not be universally accepted, but I didn't quite expect quite so... vehement a response. :-) I'll attempt to summarize the conversation thus far: * By far, the most frequent concern was that it would break Wine and Steam. * Third-party software written only for 32-bit runtimes would likely require considerable hacking to continue working under such a system. * Cross-compilers wouldn't be able to work with this system without significant modification. Two suggestions were raised as alternatives to the container approach: * Switch to using the Debian style of multi-arch layout, which instead of /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this would include the emergence of a de-facto standard for system layout between the major distributions. * Ship only one arch in the repositories and allow users to trivially enable the repositories for other arches through DNF if they have need. Those two suggestions are not (to my mind) incompatible with one another and their combination may indeed prove to be a superior solution to the one I initially came up with and suggested. I feel it necessary to point out some of the (surmountable) issues that such a transition would face. == multi-arch layout == * Moving the locations of all of the system libraries would potentially still break third-party applications that were compiled to expect libraries to be in the /usr/lib[64] paths. This would be a similar problem to the UsrMove change and would likely be solved the same way; by maintaining symlinks in the old locations for some reasonable migration period. Given the enormous number of packages involved and the fact that it's not a simple directory rename, we may need to add a hack into rpmbuild to automatically generate these symlinks in the old location. * Switching to this layout might give a false (or possibly accurate, in some cases) impression that one could expect Debian/Ubuntu packages to function "out of the box" on Fedora (if using something like Alien). Education is key here. == Separated Repositories == This one is actually a lot harder than it might appear at first look, mostly due to the way our packaging dependencies are written. In many (most?) cases of arch-ful packages, their dependencies are likely to be specified without the %{?_isa} suffix. As a result, if we were to just blindly add the i686 repository to a running x86_64 system, even at lower priority, there would be times when an update would attempt to pull in the wrong architecture's package (consider situations where the i686 mirror the user is connected to may have synced already, but their x86_64 mirror has not). The user would inadvertently pull in the wrong version of a dependency and their application or service might fail to start or function unexpectedly. So if we were to go this route, it would mean a great deal of work fixing up hundreds (if not thousands) of spec files to add explicit architecture dependencies, or else new functionality in DNF/libsolv to ensure that architectures don't change in a transaction. Or, ideally, both. I think there is a lot of potential with these ideas (and they're compatible with our plans for modularity as well). Would people be willing to participate in such a task if we were to undertake it? Similarly, I'm sure there are other "gotchas" hidden here that I didn't immediately come up with. What other issues am I missing? I assume we made the decision to do /usr/lib[64] in the first place for good reasons; What were they, and are they still valid?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org