Nicholas Miell wrote:
On Wed, 2004-12-01 at 12:07 -0500, Jeff Johnson wrote:
OK, to summarize:
a) There's a whole lot of pain and not much gain messing with package file names (and file paths and scripts and ... )
b) The dependency
Requires: cpu(cmov)
(or equivalent token) might (*will* imho) be useful identifying packages that actually use, say, cmov.
(Note: there's more than cmov that needs marking, generalizing the cpu(...) name space is quite straightforward.)
c) Users want a clear call on what package file name to install, as some *.i386.rpm will not run on arch i386, very confusing.
d) linuxthreads needs to die! die! die! (but that's just me ;-)
Name your poison (if any) please.
What's going to Provide: cpu(cmov)?
Can be done by simple string in per-arch kernel package right now, although
that doesn't really solve the problem adequately, as dependencies in packages
are static content. But even a static dependency would be as good as, say
Provides: kernel-abi = 2.6
Prolly the strongest mechanism is to attach a run-time probe dependency to the "cpu(...)"
name space and parse /proc/cpuinfo for the relevant info. That mostly works, but
will have problems in chroot's w/o /proc mounted, and will be kinda weird if/when, say,
the mobo or disk is moved amongst machines, to mention just 2 possible problems off
the top of my head.
I suspect those deficiencies can be lived with, and are no worse than existing arch based tests.
It's not like a missing dependency is gonna explode somebody's monitor or anything
really seriously deadly or risky ... NPTL was far far riskier than what I am humbly proposing ;-)
73 de Jeff
