[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Merging dpkg-cross into the dpkg source

On Fri, 20 Feb 2009 16:08:45 +1030
Ron <ron@debian.org> wrote:

> 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. 

/etc/dpkg-cross/archtable.d/ could be extended for that purpose -
it's a much better idea than the legacy method of hardcoding such
variants into dpkg-cross itself. It was originally designed for this
situation, so if it isn't suitable, it needs to be fixed. See #447427

> The rationale is, things like arm and uclibc have many possible variants,
> and we cannot possibly provide them all by default. 

archtable.d/ was meant for this support - although the name does tend
to indicate only one side of the table but that can be changed.

The questions are:

1. Do you need to alter ostable, archtable and tripletable or can we
arrange a method to host all three in one file/directory? Combining the
tables requires an element of rigour to the definitions and should
prevent overlaps or omissions.

2. Do you need dpkg to support this directly or will support via other
tools be sufficient? (i.e. as now with archtable and dpkg-cross). If
so, which tools? (bearing in mind that dpkg-cross itself will

Maybe what we shall end up doing is migrating the package conversion
routines from /usr/bin/dpkg-cross into dpkg|dpkg-dev using multi-arch
support and implementing the architecture-support configuration of
dpkg-cross as a configuration package that handles the static data like
cross-config. $arch, archtable.d/ and the rest in /etc/. The only issue
for me is about the status of multi-arch in Debian - where are we at?

> 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.

To do so, you may well need to also modify the cross-config.cache
values as these provide the results of macros run by autoconf based on
a standard Debian system. If uClibc or any other variant changes the
behaviour of functions compared to standard glibc and standard Debian,
the variant would also need to take account of these changes.

> 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.

Then what we need is a test suite for these systems whereby we get the
results of the ./configure tests performed by each package currently
supported by /etc/dpkg-cross/cross-config.cache or putting files
into /etc/dpkg-cross/cross-config.d/ in a native build and then
reporting back on any changes in the cached values. There is a
prototype script to do that kind of thing in emdebian-tools already,
emcache. Patches to modify it for such a test suite would be
welcome. ;-)

> 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.

OK, so which executables and which routines need to call these values -
would support inside dpkg-cross be sufficient or are you seeking for
dpkg to support /etc/dpkg/arch.d/ instead?

Most of the support you need does exist but it sounds like it needs to
be optimised. There is no need to alter /usr/share/dpkg/ostable
or /usr/share/dpkg/tripletable anymore - that support should be
possible via /etc/dpkg-cross/archtable.d/ and if that isn't working, I
would appreciate a patch to get it working.

> 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.



and #447427


Ron - is there a reason why the support added for that bug fix is not

What needs extending?
> Debian can never provide all of those, but making them easy for people
> to build themselves is definitely a desirable goal to pursue ...

The only question is which package should be expected to provide it. If
it is the cross-config package, you will need to fold that support into
whatever scripts need the support. If you're using emdebian-tools, then
the best place is the cross-config package.

> 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.



Neil Williams

Attachment: pgpKAWC1y4ZIX.pgp
Description: PGP signature

Reply to: