i486 base architecture

[Jeff Johnson]

Nicholas Miell wrote:

>On Thu, 2004-12-02 at 20:27 -0500, Jeff Johnson wrote:
>  
>
>>Nicholas Miell wrote:
>>    
>>
>>>Ok, now that that's settled, how are packages going to get the
>>>"Requires: cpu(cmov)" dependency?
>>>      
>>>
>
>  
>
>>Again, there's nothing (well you are gonna need a matching Provides: 
>>somehow) stopping anyone from adding
>>    Requires: cpu(cmov)
>>to a package spec file, presumably because cmov is known to be used within
>>package executable.
>>
>>The process can be done automagically as well, basically disassembling 
>>every elf file and grepping for known i686 specific opcodes. That mechanism
>>is crude enough that perhaps some compiler geek would suggest a better
>>mechanism almost instantly ;-)
>>
>>    
>>
>
>Both options appear to be fragile and error prone.
>
>Requiring the manual addition of a dependency to the spec means lots of
>package authors are going to forget to do it, making it effectively
>useless as an indicator of what packages actually require (especially
>because i686 packages already require CMOVcc).
>
>Automagic dependencies are going to screw up for any piece of software
>that selects different CPU optimized routines at run-time, some of which
>use CMOVcc.
>
>  
>
>>>And why can't we just say that i686 packages all require a i686 variant
>>>that provides CMOVcc?
>>>      
>>>
>
>  
>
>>Because that is exactly where rpm is right now, with murky and implicit 
>>assumptions about what is provided and what is not, and no clear way to 
>>identify without the artifact of inventing bogus i686 arch names (kinda
>>like ppc* is today, there's way too many ppc* arches, and I certainly
>>have no idea what distinguishing properties each has, other than
>>different letters after "ppc")
>>    
>>
>
>Well, instead of weird Requires that have to be manually inserted by the
>spec author and Provides that are mysteriously provided by nothing, why
>not just document exactly what the different RPM architectures mean.
>  
>

The package maintainers for the handful of packages that use, say, cmov 
are quite
knowledgeable and competent. Requiring manual entry is also a viable 
solution to
the general problem because a missing Requires: changes nothing that is 
not already
happening in practice, that, indeed, there are implict and undocumented 
dependencies
in existing packages.

But I'm all in favor of automation, do not think that I am suggesting 
manual package
edits as the best possible solution.

The rpm implementation does not control what strings are used to 
identify arch in packages.
For example, PLD is using "pentium3", "pentium4", and "amd64" while
Red Hat is using "i586", "i686" and "x86_64" with essentially the same
meanings, and all of those strings are being carried in default rpm 
configuration.

Documenting what is meant by all those strings that are used differently is
a vendor or distro, not an rpm, problem. The rpm implementation supports 
only the
strcmp mechanism, not the deeper semantic meaning of arch.

And the "weird Requires" is actually an attempt to rationalize this mess,
as arch in rpm is entirely the wrong name space to tag packages with,
there are way too many problems to do anything other than just
abandon arch as a meaningful objective identifier of rpm package content 
imho.

>This isn't as hard as you may initially think -- just say that each
>target requires whatever gcc requires when optimizing for that target
>with the default RPM build flags.
>  
>
That has already been attempted, the configured optflags (which is all that
rpm has ever attempted to control for when building a package) have been
in packages for years.

That of course doesn't work at all when packages do not use $RPM_OPT_FLAGS.

Attempting to reason from what gcc uses also does not "work" when there 
are, say,
several different sets of compilation flags used within a single 
package, so there is
no one "target requires whatever gcc requires", the mapping is many 
files within
the package compiled by gcc onto a single package arch identifier.

>  
>
>>>Sure, there are i686 variants that don't, but what's stopping them from
>>>using the generic i386 version (which is optimized for i686, anyway)?
>>>
>>>      
>>>
>>And that is the lowest common denominator package naming that is 
>>currently being used in FC4, some packages have ".i386.rpm" suffixes, yet
>>will not run on hw arch i386, causing user confision about every 3 months
>>or so, and we discuss this topic Yet Again.
>>    
>>
>
>Well, that's a bug, those packages should be fixed.
>

How, by changing the label from "i386" to "i486" or
by changing the compilation to agree with the label?

>
>And if you get tired of user confusion, make a FAQ. Saying "It's in the
>FAQ, dimwit." or something to that effect can be rather satisfying.
>

Easier than a FAQ is not making any change at all (i.e. leaving packages 
as "i386.rpm"),
which appears to be where this thread is ending up, not surprisingly.

Talk to you in a couple of months, when the "i386" vs. "i486" issue will 
surely arise again,
same Bat time, same Bat channel ;-)

73 de Jeff