Re: Merging dpkg-cross into the dpkg source
Hi!
On Wed, 2009-02-18 at 13:44:30 +0000, Neil Williams wrote:
> dpkg-cross 2.4.0 is now in unstable and has had a lot of outdated
> cruft removed during the Lenny freeze. I'd like to start the process of
> removing dpkg-cross itself and providing all functionality via
> dpkg/dpkg-dev.
To refresh my memory I've checked some conversations we had some time
ago (around 2007-08 and 2007-10) on IRC about the merge. And something I
mentioned back then, and keep thinking is that what we really need to
make dpkg-cross disappear, is to implement multiarch support. At the
time I mentioned I was fine with having the crossbuild directories
handled from dpkg-dev scripts, as long as this was considered
experimental support, and that we could break/change that later on.
After skimming over the dpkg-cross again, I see that it's mostly
trying to implement multiarch, execept that it uses the crossbuild
directories instead, and mangles the packages and its contents to be
able to install them natively. That's something I don't really want to
see merged in dpkg. Multiarch would just make all this unneeded.
Additionally the gccross thing (with the symlink farm) might also become
irrelevant with multiarch as the .la, .pc and similar files would get
installed in the multiarch dirs with the correct paths already, so no
further mangling at build time would be needed.
> Questions:
>
> 1. Should dpkg-cross remain as a discrete executable or as
> functionality of another executable in dpkg or dpkg-dev?
Ideally dpkg-cross would be empty, dpkg and dpkg-dev should provide
cross build support natively. Something that you requested back then
on IRC was a dependency on binutils-multiarch, but we said we didn't
think that was appropriate, and what Raphaël proposed which is also
what I think makes sense is to introduce a cross-build-essential (or
similar) if we really need such thing.
Anyway, if there's really a need for a dpkg-cross produced from dpkg
sources we can have it, but I don't think this is important at the
moment.
> 2. How to retain the *very* useful "default cross-building architecture"
> and associated debconf support, depending on the answer to Q1.
Maybe it would be better to handle this as alternatives for the
default cross toolchain, instead? But I've not thought about this
much. We can sort it out once we have the foundation set up.
> 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.
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.
> 4. Which package should take on the hierarchy of cross-configuration
> conffiles in /etc/dpkg-cross/ ?
The autoconf config.cache failes 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. 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.
> 5. What needs to happen to the perl module (currently
> Debian::DpkgCross) - apart from the pending removal of all legacy code
> (already marked as such in the module).
I guess once it's not needed it can just vanish.
> 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.
regards,
guillem
Reply to: