State of multilib development

[Linus Walleij]

Hi Hans, I think these issues are highly important, because they prepare 
us for the 64bit future. However I think the audience is small and that is 
why so few comments arrives.

I'll do my best, though I'm a i386 owner, sadly.

First, is the rest of the world we live in really aware of setarch or is 
that perceieved as some RedHat weirdo thing that they never heard of? Then 
we'll have to evangelize it.

Secondly, are there other things that setarch could/should do apart from 
just altering the output of uname -m as it does today? If there is, it'll 
sure turn up in the suggested bugzilla tickets...

In any case I think setarch has a clear use in not only cross-building, 
cross-packaging, cross-installing i386, x86_64 or PPC, it should also 
have a place in embedded development as for ARM etc.

On Thu, 19 Oct 2006, Hans de Goede wrote:

[GCC]
> I personally would expect setarch i386 gcc -o hello helloworld.c" to
> create an i386 elf binary, I haven't filed a bug for this though,
> because I believe the current behavior is intended, unfortunate but
> intended.

Why? I would file a bug and let the GCC developers decide on how to handle 
this. Better file one too many than one to few bugs is my stance. "Please 
get the default arch as from uname -m" is just fine, isn't it?

[rpmbuild]
> I however still believe that rpmbuild should change its default build
> target when using setarch and should call setarch itself when called
> with --target, shall I BZ this?

Since both setarch and --target seems to be required there is something 
fishy. Why tell the tool the same thing twice? I think you're right and 
the bug should be filed.

[pkgconfig]
> Shall I BZ this?

Yes, I think so.

[rpmbuild again, but worse bug]
> Suggestion: make rpmbuild check the arch of BR's who's name ends with
> -devel.
> (...)
> This will still have a few exceptions, but will be a big improvement in
> general. BZ?

Yes.

[yum]
> xxx-devel.arch should require xxx.arch not just xxx
> When I install libXt-devel.i386 I expect it to drag in libXt.i386 and
> not to be happy with the already installed libXt.x86_64 .
> (...)
> Once more if people agree with me here I'll put this in bugzilla.

I agree, this is more serious than the build tool issues, since it affects 
end-users badly.

Isn't the idea that i386 should be used as a fallback on x86_64 if and 
only if no x86_64 package can be found? That's atleast what I see as 
consensus. So that's how yum should operate, right?

Linus