On Tue, 27 Dec 2005 12:22:30 +0100, Sven Luther <[EMAIL PROTECTED]> said:
> On Tue, Dec 27, 2005 at 03:36:46AM -0600, Manoj Srivastava wrote:
>> On Tue, 27 Dec 2005 09:44:20 +0100, Sven Luther
>> <[EMAIL PROTECTED]> said:
>> And the kernel architiceture is what is passed to the kernel
>> Makefile as ARCH=ffo, and kernel-package stores it under
>> KERNEL_ARCH
> Indeed, and it happens that all manner of tools break when the
> debian architecture (the one returned by dpkg-architecture) is
> different from the kernel architecture (the one you set ARCH=foo
> when building the kernel).
Well, break is a strong word. We handle this all right now
in amd64, for instance.
it does not. ANd neither does amd64 break.
> That is not what fs was saying earlier, as amd64 has the same
> problem of the kernel arch (x86_64) being different from the debian
> arch (amd64).
Ah. You are basing assertions on ancient hearsay. This
assertion no longer holds.
> There is at least a problem in the documentation, if nothing else,
> but it is not like your comments where helpful in making things
> clearer, which sucks. But we solved the issue on irc, but i think
> this is a problem in the usefulness of using debian bug report for
> communicating about a bug or something.
Err, the issue is also you coming in and making strange
assertions and allocating blame, and holding strong views you are
unwilling to change -- which makes working together hard, especially
since you keep telling me I am wrong about how k-p should do things.
> Nope, and this is the main problem here, that the dpkg-*
> architecture is not the same string as the kernel expect.
However, what we pass in as --arch is $(architecture) -- which
is not what we pass in to the kernel, which is $(KERNEL_ARCH). There
is no reason why $(architecture) and $(KERNEL_ARCH) should be the
same string.
>> No, ARCH is the wrong thing to set here. We should be using
>> --subarch.
> Yeah, altough --kernel-arch as an override to whatever --subarch
> sets as default would be a good feature, i believe, and rather cheap
> to do even.
It is added, duplicate code. Any duplicated code is bad.
>> --arch is DEB_HOST_ARCH_CPU (or DEB_HOST_GNU_CPU, if that does not
>> exist). If you tell kerel-package some value of arch that is
>> different from DEB_HOST_ARCH_CPU, kernel-package knows you are
>> cross compiling.
> Indeed, but the kernel arch is different.
Correct. Hence using --arch does the wrong thing.
>> You are wrong about that. kernel-package _defaults_ to setting
>> kernel ARCH to be the same as DEB_HOST_ARCH_CPU, but does not
>> _assume_ they are the same. Big difference.
> but you have no way of setting it to something different, except by
> editing the arch-specific snipplet.
There should be no reason to set it, unless there is a bug in
kernel-package. In which case it should be fixed, so that every one
benefits, not just the person who figured it out.
> Ok, i think we should kill ppc.mk and ppc64.mk and work things out
> in powerpc.mk. I will provide you a patch this evening.
As long as it still works with 2.6.14 kernels, and 2.4.X
kernels, I have no objection.
manoj
--
Preudhomme's Law of Window Cleaning: It's on the other side.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
