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 disappear). 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. http://lists.debian.org/debian-embedded/2007/05/msg00061.html http://lists.debian.org/debian-embedded/2008/07/msg00025.html and #447427 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=447427 Ron - is there a reason why the support added for that bug fix is not suitable? 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. True. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpcNEuzCH6Wf.pgp
Description: PGP signature