Re: Bug#447427: dpkg-cross: please support wrong architecture
On Mon, Oct 22, 2007 at 10:45:39AM +0200, Jonas Meyer wrote:
> On 10/22/07, Neil Williams <codehelp@debian.org> wrote:
> > On Sun, 21 Oct 2007 08:37:38 +0200
> > Jonas Meyer <quitte@gmail.com> 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
Reply to: