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.
And that is the lowest common denominator package naming that is currently being used in FC4, some packages have ".i386.rpm" suffixes, yetSure, there are i686 variants that don't, but what's stopping them from using the generic i386 version (which is optimized for i686, anyway)?
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
