Re: Debian GNU [was: smarter way to differ architectures needed?]
In message <[🔎] 19990415092658.8728.qmail@snoopy.apana.org.au>
bam@snoopy.apana.org.au (Brian May) wrote:
[snip]
> 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?)
To execute code in a particular instruction set hardware support alone is
not sufficient, kernel support may also be required. Furthermore, most
packages do not use the full capabilities of the processor, therefore
a emulator may not supply the full functionality of a processor.
I suggest that hwarch-foo can only be installed on hardware foo and
provides hwiset-bar for each instruction (sub-)set foo provides. The
kernel will then provide kernel-support-bar or module-support-bar
for each hardware supplied instruction (sub-)set it supports, and
provide kernel-bar or module-bar for each instruction (sub-)set
it provides (eg. floating point emulation). A emulator will
provide <package>-bar for each instruction (sub-)set it provides,
where it can execute each of those instruction (sub-)sets in the
same process.
Several packages will depend on kernel-support-bar and hwiset-bar
and provide kernel-bar, likewise several packages will depend on
module-support-bar and hwiset-bar and provide module-bar. Everything
which provides kernel-bar will also provide module-bar.
Now it gets rather difficult, as we need insure for each executable
and the shared libraries it uses there is a <package>-bar for each
instruction (sub-)set it uses where <package> is the same. I suggest
that Depends: lines like (for example):
Depends: librose.so.1 = iset-arm32l + iset-arm_fp_base + libc.so.6,
iset-arm32l + iset-arm26l + iset-arm_fp_base + iset-arm_fp_ext
+ iset-linux_arml + iset-linux_arm_iset + libc.so.6, gnome-core
This package contains a library (librose.so.1) which requires a ARM 32-bit
little endian instruction set, basic ARM floating point and glibc. It
also provides a executable which requires a ARM 32-bit little endian
instruction set, a ARM 26-bit little endian instruction set, full ARM
floating point, a Linux/ARM little endian system call interface,
a Linux/ARM system call to switch instruction sets and glibc. For
some reason this package also requires gnome-core. Note that I have
treated system call interfaces the same as instruction sets, and that
normal (virtual) packages can be used with the + operator.
Currently we have libraries which share the same soname, but are binary
incompatible (as they have been compiled for different architectures),
this could be solved by putting a identifier for the binary interface
in the soname or put them in different directories. It is also possible
that in the future ld.so takes care of instruction set dependencies.
User-Agent: POPstar/2.01b11
This solution solves most problems of the solution currently being
discussed, except that does not cater for SMP systems dis-similar
processors.
[snip]
> >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.
Especially as they could be very hardware dependant.
[snip]
--
http://www.reinhouse.freeserve.co.uk/
PGP key fingerprint = D6 FA 76 1D 68 F6 7B 96 F4 BC F2 62 D2 02 62 8E
Read the uk newsgroups? Then read uk.net.news.announce
Reply to: