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?
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
