On 01/05/2017 11:42 AM, Tom Hughes wrote:
On 05/01/17 16:38, Thorsten Leemhuis wrote:
> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
>> [...]
>> ## Advantages
>>
>> * Simplification of build-tree creation. We wouldn't have to maintain the
lists
>> and hacks that are required to make sure that multilib packages land in the
>> correct repositories.
>> [...]
>
> Just wondering: Why don't we switch to a multilib/multiarch solution
> similar to the one that Debian/Ubuntu uses? They put libs in directories
> like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
> (
https://wiki.debian.org/Multiarch/Implementation
>
https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar
> solution a new (de facto) standard might evolve and in the end nobody
> would have to deal with hacks any more, because all major distros would
> put libs in the same directories. Iirc their model has benefits for
> cross-compilation, too.
That's exactly what I thought was about to be proposed when I saw the subject of
the email and I got excited for about 30 seconds until I read the body ;-)
If we end up staying with a multilib approach, there's certainly a lot of merit
to developing a cross-distribution standard.
However, it still doesn't solve the problem that we have today, which is that we
have to do a lot of hacky shuffling around of packages in order to take packages
built in i686 and drop them onto the x86_64 repository.
It might be different if we could build 32-bit sub-packages in the 64-bit mock
environment, but the tools are *really* not equipped to handle that today (in
particular because Fedora doesn't do cross-compilation; we just spin up a
builder of the actual hardware it should run on.)