Re: Debian GNU [was: smarter way to differ architectures needed?]
Gordon Matzigkeit wrote:
>[Brian, your summary of the idea is nearly perfect. Thanks for taking
>the time to explain this in a clear way that I wasn't able to. I
>really depend on people such as you to interpret my grunts and
>hand-waving and come up with a coherent explanation that makes sense
>to other people. ;)]
I hope so. I just thought I was turning you grunts and hand-waving
into my grunts and hand-waving ;-)
>To reduce confusion: the new symbol we're talking about is really just
>`XOR' (exclusive OR), and the old symbol is `OR' (plain old inclusive
>OR). In keeping with dpkg's convention of using the C bitwise
>operators, let's make the new operator `^' instead of `||'.
>
>I also like using `hwarch-i386' instead of `arch-i386' to make it
>clear that we're describing only the bare hardware.
>
>I've edited your quotes accordingly.
Agreed.
> BM> Depends: hwarch-i386 ^ hwarch-sparc | hwarch-somethingelse
>
> BM> would be illegal as it is ambiguous. Sure, there are ways around
> BM> this (ie use brackets) but I don't see any real need. Please
> BM> tell me if I am wrong (give examples too).
>
>I agree with you.
How about something like:
Depends: hwarch-i386 | hwarch-sparc
?
On the plus side (I won't state the negative just yet) this is already
supported by existing tools. (not that I can see any need for it, yet).
> BM> Also, some names need to be given. I previously thought of using
> BM> "os-any" to mean "hurd ^ linux ^ ..." but Gordon disliked
> BM> it. What is a better name? "kernel-any"?
> BM> "idontknowwhatthisfieldshouldbecalled-any"? ;-)
>
>The only reason I disliked it is I couldn't think of any reason why
>this field would ever be necessary.
>
>Now, I guess it would be useful for at least glibc. In that case, the
>keyword I like best is `kernel-any' -> `linux ^ hurd ^ ...'.
Hang on - I think I read you now. You are saying that most programs
should depend on the specific glibc version rather then the kernel. If
the same glibc was used both on Linux and Hurd, would the same binary
run on both?
ie I think you have said (I haven't checked) that most packages would
have:
Depends: hwarch-all, glibc
If I am wrong on this assumption, then skip the rest of this section ;-)
However, this falls apart if you have Hurd programs that
skip glibc altogether and talk directly to the Hurd tasks (this
is meant to be faster). I am not sure I like giving these
"kernel-all", as Hurd is probably the only special case. Comments?
One potential solution that immediately comes to mind (making
assumptions that I have been correct on all of the above):
Depends: hwarch-all, hurd ^ glibc
(this of course is a bit weird in that a hurd system also has glibc,
comments?)
I have a few other ideas myself, but I won't state them yet until read
I have the replies to this (otherwise some-one will tell me I was
wrong from the very start ;-) ).
> BM> C. Packages would have to be installed to provide packages like
> BM> "hwarch-i386", "linux" and "hurd". Would these need protoection
> BM> against installation on incompatable architectures?
>
>Absolutely not!
>
>It should be possible for somebody running Debian GNU/Hurd on a Sparc
>to install a binary package that `Depends: hwarch-i386, linux' if they
>really wanted, given that some package on their system had the needed
>`Provides'. Presumably, that package would be a kind of i386
>emulator.
Maybe you misunderstood me. Or maybe you have identified issues that
I may have missed ;-)
To clarify my thoughts (for your example of i386 emulation on Sparc):
hwarch-i386 package would only be installed on hwarch-i386. It
could have some check to ensure that the architecture was
compatable. After all, you can't have hwarch-i386 depend on its
self ;-), and it would be wrong to try and install hwarch-i386
on something that can't support this instruction set without
an emulator.
The i386 emulator for sparc would provide (and hence conflict with)
the hwarch-386. It would depend depend on the hwarch-sparc.
Hence it doesn't conflict with your goals (or have I missed something?)
Later on, if this ever were implemented, I would think it would
be really important to have some tool to show which packages
need emulation to run.
I am not sure what benefit emulation would provide though, except
perhaps for non-free packages where source code is not available
or if it is too difficult to port to another hwarch.
>I know that the technology doesn't really exist now, and that there
>are many complicated issues surrounding this question, but we should
>at least try not to gratuitously obstruct the people who want to work
>on those issues.
Strongly agreed.
>I think that an essential required base package should Provide the
>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.
>Kernel packages, however, provide themselves, and there should be
>nothing preventing people from changing kernels without reinstalling
>the whole system.
The only potential problem I see here, is if a program directly
accesses the Hurd layer (I think I saw someone saying somewhere that
this was desirable and required for maximum speed), it may have to
be recompiled/reinstalled to run under glibc again.
Again, I have a few ideas myself, but I won't state them yet until
I have read the replies to this.
Brian May <bam@snoopy.apana.org.au>
Reply to: