i486 base architecture

[Nicholas Miell]

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.

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.

> >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.

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.

-- 
Nicholas Miell <nmiell at comcast.net>