On Thu, Jan 5, 2017 at 7:20 PM, Josh Boyer <jwbo...@fedoraproject.org> wrote: > On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher <sgall...@redhat.com> wrote: >> 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. > > * Represents a significant change to how end-user developers will need > to build software. > >> 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. > > What does SuSE do for multi-lib? Or Arch or Gentoo? I don't think > Fedora switching would mean a de-facto anything. >
SUSE does multilib in the same style we do. Arch and Gentoo use /usr/lib32 for 32-bit libraries, and /usr/lib64 for 64-bit libraries. Both distros are also working on /usr/libx32 for the x32 ABI support, so they're doing three ABIs in parallel, as opposed to our two. >> * 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. > > Why wouldn't you have the rpm macros package automatically include the > %{?_isa} suffix in all built packages? The RPMs are built in > arch-specific chroots, so if it was done automatically it would likely > just need a mass rebuild? Am I missing a reason that wouldn't work? > We build noarch packages in archful chroots, so we'd accidentally break noarch package builds pretty often that way. -- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org