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(a)comcast.net>