Re: Debian GNU [was: smarter way to differ architectures needed?]
>>>>> Marcus Brinkmann writes:
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').
MB> We have quite a lot of Linux dependent packages, don't forget the
MB> networking stuff, the /proc stuff and the other kernel related
MB> tools.
That's true. I guess I'm only talking about the packages that are
intended to be portable, or that don't depend on Linuxisms.
MB> BTW, what is wrong with the existing GNU nomenclature?
MB> CPU={i386,sparc,...} # "hwarch"
MB> SYSTEM={linux,gnu,...} # "kernel", "os"
MB> You already said why you dislike cpu. But we should really think
MB> twice before introducing yet another different nomenclature, and
MB> consider staying with existing terms.
The PC98 machine used in Japan is an example of a machine that uses an
i386-compatible chip, but whose hardware architecture is incompatible
with the IBM PC. I suggested `hwarch-*' to avoid the situation where
we have to split up the `cpu-*' packages according to hardware
architecture incompatibilities.
We can first migrate to `hwarch-*', then later distill out the
packages that truly depend only upon the CPU of the machine, once
there is a need to do so.
This follows the general principle of being as specific as possible,
only generalizing when you have a good reason to do so, in order to
minimize the number of times you have to undo an incorrect
generalization.
MB> Maybe you should try to get the GNU nomenclature changed first if
MB> it is that important?
hwarch == CPU-VENDOR (no OS or kernel)
So, maybe I should make it `hwarch-i386-pc', to distinguish from
`hwarch-i386-pc98', which doesn't exist yet.
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
MB> What about gdb?
Yes, you are right. I just wanted to point out that there will
probably be more packages that have no kernel dependency than ones
that do.
MB> I am looking forward to read your draft for an proposal!
Good! I'll be sure to put it together as soon as I have time. :)
--
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: