config.guess manufacturer string?

Ralf Corsepius rc040203 at freenet.de
Fri Feb 20 08:55:27 UTC 2009


Jakub Jelinek wrote:
> On Fri, Feb 20, 2009 at 10:18:04AM +0200, Panu Matilainen wrote:
>>> Can someone let me know what the outcome of this is with regard to
>>> redhat-rpm-config? I'm cool with making changes to the default
>>> config.guess if they're deemed necessary to bring back "redhat" for the
>>> time being.
>> I think patching config.guess has been ruled out by everybody, and that  
>> %configure needs to stop setting --target and --host. But whether  
>> %configure should set --build to <arch>-redhat-linux or just let  
>> config.guess decide... at least Jakub seemed to want to stick with  
>> <arch>-redhat-linux instead of pc|unknown|whatever.
 >
> If you don't pass --build, how will it find out i386 vs. i586 vs. i686
> based on how rpmbuild was invoked?

Except of very few rare exceptional cases you don't have to know it.
And when, you can always manually add --build to these package's specs.

Otherwise, appropriate CFLAGS will implicitly do it for you (when using 
rpmbuild, rpm is supposed to do this).

Also, adding --build to %configure will only override $BUILD when 
building rpms. It will not help users configuring packages in ordinary 
shell environments, but preserve the inconsistence there.

IMO, to make this working you will have to adjust the origin of the 
MANUFACTURER string, i.e. to fix uname(), such config.guess reports what 
you expect.


>  Without --build, it will be always
> i686 in those cases.  I think you need to keep passing --build and I'd
> appreciate if redhat could be in its argument.

Is there any actual use case where you need *redhat*? Marketing purposes?

(In this case, pedantically speaking, I would have to insist on using 
"fedora" instead, because Fedora is not a RH product and RH is not it's 
manufacturer.)

Anyway, I'm only aware about one such case: Setting the target tuple of 
a small number of toolchain packages.

All other cases are mere "string" pass-throughs without technical 
necessity nor use.

Ralf




More information about the fedora-devel-list mailing list