>>>>> Brian May writes: BM> I hope so. I just thought I was turning you grunts and BM> hand-waving into my grunts and hand-waving ;-)
ROTFL. BM> How about something like: BM> Depends: hwarch-i386 | hwarch-sparc Oooh. That should be legal. All that refers to is a package which determines at runtime which hardware optimizations to use. I can't think of any such package right now, but we shouldn't rule them out. >> Now, I guess it would be useful for at least glibc. In that case, >> the keyword I like best is `kernel-any' -> `linux ^ hurd ^ ...'. BM> Hang on - I think I read you now. You are saying that most BM> programs should depend on the specific glibc version rather then BM> the kernel. Nearly every program will depend on the specific glibc soname (i.e. libc5 or libc6 on Linux, libc0.2 on the Hurd). Only some programs would depend on the kernel *in addition to* libc (such as modutils, which would have `Depends: linux, libc6'). BM> If the same glibc was used both on Linux and Hurd, would the same BM> binary run on both? Bingo. BM> ie I think you have said (I haven't checked) that most packages BM> would have: BM> Depends: hwarch-all, glibc [Your terminology is wrong: hwarch-all shouldn't be defined, I think you mean hwarch-any -> `hwarch-i386 ^ hwarch-m68k ^ ...'.] It's more like they would have `Depends: hwarch-any', and then dpkg would find its shared library dependencies, plus specific hardware architecture, and transform the line into `Depends: hwarch-i386, libc6'. BM> However, this falls apart if you have Hurd programs that skip BM> glibc altogether and talk directly to the Hurd tasks (this is BM> meant to be faster). The only packages that do this right now are glibc itself, and BM> I am not sure I like giving these "kernel-all", as Hurd is BM> probably the only special case. Comments? [Again, you probably mean `kernel-any' -> `linux ^ hurd'.] I agree. That's why I was reluctant to have `kernel-any' in the first place. BM> One potential solution that immediately comes to mind (making BM> assumptions that I have been correct on all of the above): BM> Depends: hwarch-all, hurd ^ glibc BM> (this of course is a bit weird in that a hurd system also has BM> glibc, comments?) You're talking in the future, when things like GNU tar compiled against libc6 (?) would work on both the Hurd and Linux, but you could also compile a special GNU tar binary that would take advantage of Hurd features and not work on Linux. There are no packages that currently fit this category right now, so we should hold off on this discussion for now. We'll scare too many people off of the `^' idea if we attach these problems to the initial proposal. BM> Maybe you misunderstood me. Or maybe you have identified issues BM> that I may have missed ;-) I think both of us have moved into the wild speculation stage. I'll ponder your ideas, but I'd rather not comment on them for the time being. Let's calm down again, and focus on the task at hand: coming up with a coherant proposal for adding XOR (`^') to dpkg, and using it to gradually replace Architecture with Depends. BM> I am not sure what benefit emulation would provide though, except BM> perhaps for non-free packages where source code is not available BM> or if it is too difficult to port to another hwarch. I'll just say one word, and leave it at that: bytecodes. >> I think that an essential required base package should Provide the >> default hwarch. Maybe that package should be `base-files'? BM> I think base-files currently has architecture set to "all"... BM> Anyway, I personally would prefer to keep them seperate. In another hour or so, I'll have submitted a proposal for how this all will work. Let's postpone the discussion until we have some common ground to work from. Thanks for your valuable comments, -- Gordon Matzigkeit <[EMAIL PROTECTED]> //\ I'm a FIG (http://www.fig.org/) Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
