On Thu, Jan 5, 2017 at 7:20 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
> 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.
>
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
