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.
* 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
