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
>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
>>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
knowledgeable and competent. Requiring manual entry is also a viable
the general problem because a missing Requires: changes nothing that is
happening in practice, that, indeed, there are implict and undocumented
in existing packages.
But I'm all in favor of automation, do not think that I am suggesting
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
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
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
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
This isn't as hard as you may initially think -- just say that
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
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
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
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
surely arise again,
same Bat time, same Bat channel ;-)
73 de Jeff