On Mon, Oct 22, 2007 at 10:45:39AM +0200, Jonas Meyer wrote: > On 10/22/07, Neil Williams <[EMAIL PROTECTED]> wrote: > > On Sun, 21 Oct 2007 08:37:38 +0200 > > Jonas Meyer <[EMAIL PROTECTED]> wrote: > > > To create toolchains that have a new debian name than an already existing > > > architecture it'd be useful if something like this worked: > > > > > > dpkg-cross -a uclibc-mipsel -i libc6_2.6.1-6_mipsel.deb > > > dpkg-cross: libc6_2.6.1-6_mipsel.deb has wrong architecture (mipsel) > > > dpkg-cross: conversion of libc6_2.6.1-6_mipsel.deb failed. > > > > > > Please consider adding an option to disable that check.
We don't need to disable this check if the correct dpkg foo-table entries are added for the desired arch, right? So once dpkg-architecture et al. all behave as planned, all that remains is to have a 'proper' way to extend those tables for any 'unofficial' archs that people require. > I'm assuming that adding uclibc-foo like I described here: > http://wiki.debian.org/EmDebian/UclibcToolchainBootstrap > is the right way to do it. Right now I think that is more like the 'only' way to do it. It is not the 'right' way to do it because any local additions will get stomped by the next dpkg update that happens on the system, and those files are mostly intended to list the 'official' arch definitions. Once we start talking about uclibc permutations they quickly become far too numerous to feasibly make them all 'official' from the outset (think mmu or no-mmu variants, and there are many other desirable but mutually incompatible configurations that people will want to use). So I think what we need here is for dpkg tools to also read from any foo-table.* files that exist in /usr/share/dpkg/. Then you can add these custom arch definitions in ostable.myarch etc. where they won't get stomped by dpkg updates, and enable them to be provided by a separate package that 'defines' the new arch that is desired in a fairly well defined way. It shouldn't be too hard to add support for this to dpkg, and it has been discussed on #emdebian to a reasonable state of consensus among the participants. If no-one else has a better suggestion, and Neil and the dpkg maintainers like it, I think this is the way we should go on this. > > CC'ing debian-embedded so that others working on uclibc can contribute > > ideas on how dpkg and dpkg-cross can support unknown and new > > architectures. > I'm not sure what way of replying would be appropriate now. Please > tell me so you won't get everything three times. Probably best to discuss it to conclusion on the debian-embedded list, but I've cc'd the bug report on this one, because its the best solution I'm aware of that has been discussed to date. Cheers, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
