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