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

Re: Merging dpkg-cross into the dpkg source



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: pgpl0mfOzoWY5.pgp
Description: PGP signature


Reply to: