Re: dpkg-cross, dpkg-architecture and arch names
[ Please use my debian address as I prefer to use that hat for dpkg
stuff. ]
Hi,
On Tue, 2007-02-27 at 00:03:30 +0000, Wookey wrote:
> I noticed that dpkg-cross didn't automatically recognise armel when
> provided with an updated dpkg-architecture.
>
> This is because it has its own table of debian->gnu arch names:
[...]
> Now it seems to me that it would be more sensible to use
> dpkg-architecture to make this table. However dpkg-architecture (with
> guillem's triplet patch ported forward to 1.13.25) has a somewhat
> different table of arches. (See below - it's rather long).
That's because the patch was a proof of concept and not intended to be
used for anything outside i386/arm/armel ports. Otherwise I'd have
commited it already.
> Is there a definitive list of debian arches somewhere?
The point is not needing a definitive list. The only canonical arch
name is the one coming from the toolchain to which we do the mapping
to get the Debian arch name.
> The default list (on both patched and unpatched versions) includes a
> lot of arches that make little sense (like bsd-darwin-sh3,
> kfreebsd-s390) and doesn't include at least one that is useful for
> cross-building: win32-i386. (for use with mingw32 I think).
When the former system was replaced by the new cputable and ostable,
the idea was to be able to generate any combination of possible valid
names that could come up in the future w/o needing to add support for
those explicitely into dpkg. So if suddently somone starts a port for
kfreebsd-arm, it would just be supported.
The latter (missing win32), is a matter of adding that to the ostable,
I can do that, if there's consensus among the win32 porters.
> And all the bsd-based arches have different names, prefixed by bsd. So
> openbsd-i386 is bsd-openbsd-i386. I think this amounts to a bug
> introduced in the triplet patch (it doesn't happen in the old version)
> and should be changed to be implied in the debian arch name, as linux
> is on many arches.
Yep, but as those arches are mostly dead I didn't bother fixing for
the temporary patch.
> There are also a load of gnuaebi-linux-foo arches which are clearly
> bollocks and need removing.
Given the current implementation which combines the ostable and cputable
to generate all possible triplets and then mapping those to Debian
arches, the output is "correct" even if bogus.
That's one of the reasons I've not commited the patch (not even the
improved one I've around), because the current handling of the arches is
a bit messy. Also because it needs changing the format of the ostable,
which is something I was a bit reluctant to do before the release.
> And armel appearing twice is supicious too. Not sure where that is
> coming from.
Right, noted that on the list.
> And another datapoint is that the gcc built allows a target of avr
> which isn't in the list at all.
Then this needs to be added into the cputable, but there hasn't been
any demand so far.
> Here is the output: dpkg-architecture -L with dpkg 1.13.25 with
> guillem 'triplet' patch:
I don't think my initial patch was producing the redundant armel
entries.
> gnueabi-linux-i386
...
> armel
This one is fine is a remapping of arm-linux-gnueabi to armel.
> gnueabi-linux-armel
This one is wrong, there's not cpu called armel.
> gnueabi-linux-sparc
> i386
...
> armel
And from the position this one indicates that internally now dpkg is
considering a linux-armel arch, which is wrong as well.
> bsd-darwin-i386
...
> bsd-openbsd-sparc
And yes those two need to get the bsd- stripped from the name.
regards,
guillem
Reply to: