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. > * 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? > 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? Can you elaborate on the modularity plans, or point to a thread or documentation if you've already described 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? I have no idea. josh _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org