>>>>> Timothy Baldwin writes: TB> I suggest that hwarch-foo can only be installed on hardware foo TB> and provides hwiset-bar for each instruction (sub-)set foo TB> provides.
It would be easier to call `hwiset-*' simply `cpu-*'. In fact, that is the conclusion that Marcus Brinkmann led me to, and so it will be in my policy proposal. A lot of the complexity you are talking about is premature. Let's not worry about this until we have some real-world examples, and not just `foo' and `bar' to talk about. I think that my proposal is sufficiently general so that it won't block progress on these kinds of issues, which is the most that we can ask for without going into a lot of detail. TB> Currently we have libraries which share the same soname, but are TB> binary incompatible (as they have been compiled for different TB> architectures), this could be solved by putting a identifier for TB> the binary interface in the soname or put them in different TB> directories. It is also possible that in the future ld.so takes TB> care of instruction set dependencies. User-Agent: TB> POPstar/2.01b11 You have hit the nail on the head. This is the eventual goal, and will be the solution to the huge libtool flamewar that we had on debian-devel a while ago. It will also make things like the libc5->libc6 upgrade a heckuva lot easier. TB> This solution solves most problems of the solution currently TB> being discussed, except that does not cater for SMP systems TB> [with] dis-similar processors. That's a *slightly* harder problem than I seek to solve with my initial proposal. ;) >> >I think that an essential required base package should Provide >> >default hwarch. Maybe that package should be `base-files'? >> >> I think base-files currently has architecture set to "all"... >> >> Anyway, I personally would prefer to keep them seperate. TB> Especially as they could be very hardware dependant. Exactly. And so, I'm in the process of designing an experimental `hwarch' package which encapsulates all the Provides that the package system needs to know about the physical machine. Thanks for your comments: they definitely explore my ideas to their logical conclusion. -- Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
