Re: smarter way to differ architectures needed?
On Sun, Mar 04, 2001 at 01:14:41AM +0000, Philip Charles wrote:
> On Sat, 3 Mar 2001, Marcus Brinkmann wrote:
>
> ****
> > The problem with a new header is that you can't keep backwards
> > compatibility. In the current situation, having a new field value and using
> > an old tool will probably return an error (it should ;). With the Platform
> > field, old tools will not notice that they encounter a case they can't
> > understand correctly. Maybe we decide that this is not something to care
> > about.
> >
> > However, I have not thought this through. It's an interesting suggestion.
> >
> The problem as I see it is that we are trying to solve a two dimensional
> problem with one dimensional thinking. It won't work in the long run.
When you read http://master.debian.org/~brinkmd/arch-handling.txt, you will
find out that my imagination on this has virtually infinite dimensions, not
two or one.
The truth is that the two dimensional view on this (CPU, SYSTEM) works well
for autoconf and compilers, but still does not scale good enough for complex
packaging systems. In the above article, I try to advocate a much more
flexible way to think about architectures, based on the *interfaces* the
architectures provide.
Just one example: In the mid run, the Hurd will be able to run Linux
binaries, if they don't use kernel syscalls directly, but just glibc and
other libraries. Why should we recompile such packages? The linux i386
version will work fine for us. Sometimes, there will be additional features
available on the Hurd, and then we want to recompile anyway (PATH_MAX,
support for translators, whatever). BSD can run linux binaries, too.
However, linux glibc based binaries parsing some stuff in /proc won't work
for us, unless we have a procfs emulation for it. This can all be expressed
in my scheme. But in a simple (CPU, SYSTEM) scheme, you can't express such
fine details.
I don't suggest to implement my scheme right now. There are some gaps in
my proposal which need some careful thought and experimentation. And the
implementation requires some more new code than a few lines here and there.
So we will go for a (CPU, SYSTEM) solution for now. If this is split in
Platform: and Architecture:, or just squeezes it into a single Architecture:
line is just a question of implementation. Both have the same complexity,
and can provide the same service. What matters more here is which fits
better with our existing tools rather than what would be cleaner. They are
both equivalent and far from perfect (see above), so why bother?
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: