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? > There's also the ELF table, but detect_arch does not seem to be used > anywhere in the pkg. If it's not really needed then just drop it. It used to be used in emdebian-tools but a lintian check script proved to be a better method. I'll drop detect_arch and the ELF table in the next version of dpkg-cross - along with other legacy code. > > 4. Which package should take on the hierarchy of cross-configuration > > conffiles in /etc/dpkg-cross/ ? > > The autoconf config.cache files are not really specific to dpkg, so > it might make more sense to provide them somewhere else. They could be > used to speed up a bit normal builds as well. It would also make sense > to rename them to contain the gnu-triplet instead of the Debian arch > name. That can be done - I'll do some testing. For this to work with native packages, something (probably dpkg-buildpackage) has to set the CONFIG_SITE environment variable that points to the relevant file (all of which are actually shell scripts). There is also the /etc/dpkg-cross/cross-config.d/ directory which is intended to be used by packages to drop in their own files, e.g. orbit2. The directory could have package-specific files to replace the values in cross-config.cache. I haven't made that known to the packages involved yet as there are a few issues with ensuring that values remain package-specific. I'll continue working on those. > One of the problems I mentioned was that if not explicitly > specified configure by default tries to load them from the default > prefix, which tends to be /usr/local or from the prefix specified on the > command line, which might not be always the same place for all builds. Which makes me think that dpkg-buildpackage needs to set an explicit location in CONFIG_SITE if these are going to be used for native builds. Currently, emdebuild sets it for cross-builds. > > Where do we start? > > gcc is still lacking some patches to properly support building using > the multiarch dirs, Aurélien Jarno said he would be preparing some > patches for which Matthias Klose agreed to include (at least agreed with > the idea behind the patches). > > Once we have a working toolchain we can start drafting the details for > the implementation in the packaging level, and we'll be able to test > stuff easily. Although, there's already some previous implementation > work from at least Hugo Mills and Tollef Fog Heen that I'm aware of. OK. Thanks Guillem. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpiBj5dzEahD.pgp
Description: PGP signature