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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
