Re: Merging dpkg-cross into the dpkg source
On Thu, Feb 19, 2009 at 10:24:34AM +0000, Neil Williams wrote:
> On Thu, 19 Feb 2009 08:47:47 +0200
> Guillem Jover <guillem@debian.org> wrote:
>
> > > 3. Any renaming issues or other changes required in the current package?
> >
> > There's the arch name divergences, from the IRC logs, I think most
> > should just be removed and the ones from dpkg-architecture used
> > instead. If those need fixing then we should check for each specific
> > case.
>
> The only remaining values are:
>
> armeb: armeb-linux-gnueabi
> hurd-i386: i386-gnu #XXX This differs from dpkg-architecture
> s390x: 's390-linux-gnu' #XXX This differs from dpkg-architecture
> openbsd-i386: 'i386-openbsd' #XXX This differs from dpkg-architecture
> freebsd-i386: 'i386-freebsd' #XXX This differs from dpkg-architecture
> darwin-i386: 'i386-darwin', #XXX This differs from dpkg-architecture
> win32-i386: 'i386-cygwin'
>
> Compare in each case with the output of:
> $ dpkg-architecture -a$key -qDEB_HOST_GNU_TYPE 2>/dev/null
>
> The main effect is to allow i386 in the GNU type where dpkg insists on
> changing it to i486.
>
> The mechanism itself was intended to support uClibc architectures -
> Simon?
The other issue related to this was some mechanism to permit local
definitions to be maintained in ostable and triplettable. A local.d
directory of some sort that local admin and/or packages can drop extra
definitions into seemed to be the best option last time it was discussed.
The rationale is, things like arm and uclibc have many possible variants,
and we cannot possibly provide them all by default. While we may provide
one or more of them for general use, specialised devices are each going
to want to enable or disable different (sometimes incompatible) features.
Since the majority of the > 2000 arm machine types now registered with the
linux kernel are in some way or another specialised, this is very
desirable from the point of view of manufacturers trying to get the best
performance from their devices using an OS built from Debian sources,
and cross tools on a Debian host workstation to build it all.
Delineating them by triplets works well as the toolchains and autoconf
all support this cleanly without any extra hackery required.
I've been using a specialised arm/uclibc toolchain like this with our
products since about the middle of 2007 and it's been working really
nicely. The only thing I need to keep tweaking is to add:
ostable:
uclibc-linux linux-uclibc linux[^-]*-uclibc
triplettable:
uclibc-linux-<cpu> uclibc-<cpu>
... every time I update dpkg and they get overwritten again.
This works for other 'custom' triplets in the same way, there should be
an old post of mine (probably on the emdebian list) that details the
(successful) testing I did with uclibc_foo-linux-arm type triplets that
people would be able to use for their own esoteric builds.
Debian can never provide all of those, but making them easy for people
to build themselves is definitely a desirable goal to pursue ...
There are many possible cross triplet types beyond just arm/uclibc that
would fit into this mechanism, and I'm not sure we'll ever be able to
(or want to) support them all through a single multi-arch toolchain.
Being able to extend this locally seems preferable to trying to enumerate
them all in dpkg or requiring people to 'patch' dpkg for that support.
Cheers,
Ron
Reply to: