Re: thoughts on architectures
On Sun, Feb 10, 2002 at 10:34:36PM +0100, Marcus Brinkmann wrote:
> Hi,
>
> (I am not subscribed. You might CC me on interesting threads/sub-threads)
>
> From: utsl@quic.net
> "The major oversight is that he completely fails to mention libc. And for us,
> that remains a big issue. Right now, and for immediately forseeable future,
> I'm not going to be using glibc."
>
> There is nothing special about libc. It Depends on some kernel, cpu and
> possibly other stuff, and provides a library api (soname).
>
> Sonames should be handled completely automatic by the build system (in
> Debian they aren't) with optional overrides in case of incompatible libs
> with the same soname (don't do that, though).
Like libc.so.4 on FreeBSD, soon to be libc.so.5? Not compatible with libc5 on
Linux. It's confusing, but I don't know any good way around it.
> Programs also might depend on an object format, or you might assume the
> object format is common for all programs depending on the same interfaces.
> EG, if you assume a common object format, all packages depending on
> libc.so.6 are ELF by definition. Otherwise the object format has to be
> coded into the dependencies.
Bear in mind that quite a few systems already support multiple kinds of
binaries, and there are more on the way. Sparc, ia64 and x86-64 (not sure
if x86-64 is a Debian arch yet) all can do both 64 and 32 bit binaries. I
think s390 might too, but I'm not sure. The packaging system needs to know
how to deal with the situation.
The BSDs can run Linux binaries, and also run on some of the same 64/32 bit
platforms.
> A program that depends only on i386, libc.so.6 and optionally elf, will run
> on all systems that have libc.so.6, understand the elf object format and can
> emulate or provide i386 instructions.
That's what I was looking for. Essentially, you're setting up dependacies based
on CPU and API's needed, rather than using just architecture. That's a good
idea, and I'm in favour of it. However, it won't really help me all that much,
because just about everything is going to depend on libc6, and it doesn't work
on FreeBSD.
Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to mark
it's binaries. That's how it knows when to start emulating Linux syscalls.
So it's effectively using an altered ELF format on i386, as well as a
different libc. But it's capable of supporting libc6 in Linux emulation mode.
Of course, dpkg doesn't know that...
> Philipp:
> "However, we CD image builders are simple folk with an include/exclude
> mentality and not much time for subtle distinctions."
>
> My proposal shall not worry you. A distribution will look similar to the
> distributions that exist in Debian right now. There is no need to change
> how a distribution will look to a user. For you and others, it will simply
> be a list of packages to pick from, out of a pool.
That should be correct. A distribution already is just a Package file with
references to files in the pool. No real change there. The difference would
seem to be in the generation of the Packages file.
Reply to: