Re: Debian GNU [was: smarter way to differ architectures needed?]
>>>>> 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 <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
Committed to freedom and diversity \// I use GNU (http://www.gnu.org/)
Reply to: