On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> 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.
>
>
> 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.
>
The main breakage will be dealing with programs that use RPATH and
expect 32-bit libs in /usr/lib (since we never moved 32-bit libs to
/usr/lib32). Everything else is trivial to deal with (/usr/lib64 can
just point to /usr/lib/x86_64-linux-gnu, for instance), but that will
get tricky. Fortunately, we don't have much in the way of RPATH
issues, so I don't expect this to be a big problem.
We should probably also have the /usr/lib32 symlink added to point to
/usr/lib/i386-linux-gnu for compatibility purposes, too (Gentoo, Arch,
and several other families do use that, and there's no real cost to
having the symlink there if we have full platform libdirs anyway).
> * 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.
>
>
There are definitely bugs here, as I've been integrating DNF into
Mageia, and they follow this approach currently. There are some
strange behaviors that can occur. Most of the issues have been dealt
with, but there's still a few surprises there (and I've really got to
get around to filing bugs for them, once I collect all the needed
data!).
>
> 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?
>
In the days of when we (and may other distros) did multilib through
/lib<qual>, there was not much in the way of distributions dealing
with more than one architecture, and indeed, the mere existence of
distributions with ports to non-x86 architectures was fairly unique.
However, today it is much more common, and the usage of platform
libdirs instead of /lib<qual> give us some extra advantages in the
form of being able to handle foreign architectures far less painfully.
Things like cross compiling or user-mode emulation to run foreign
binaries become a lot easier due to the number of collisions on the
file system dropping considerably.
Simply put, our world is more diverse than it was a decade ago when
multilib was worked out, and platform libdirs is probably a better way
to go now. We can do it in a way that assures compatibility with
multilib where it matters, too.
The platform libdir stuff also makes it much easier to identify
packages that are multilib safe, since libraries will be fully
namespaced in the filesystem to the platform triple.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
