Hi, On Fri, Dec 04, 2009 at 05:26:07PM +0100, [email protected] wrote:
> Let me explain, current way of building (lenny) depends on dpkg-cross > which we want to remove from the archive (not sure when, after multiarch > maybe). Yes, after a full transition to multiarch. In principle, those libraries required for the toolchain build are going to switch to multiarch before squeeze. An evil hack that might just work: As we cannot declare dependencies on specific architecture packages, I'd suggest we create a metapackage: Package: libc6-dev-armel-cross Architecture: armel Multi-Arch: foreign Depends: libc6-dev This package doesn't need to be updated as new libc6-dev packages come out, as all it does is pull in the real package from the right architecture. This does require multiarch capable apt and dpkg. > So we need to bootstrap cross tools, which has been implemented at > emdebian.org/git/buildcross.git. The only problem is to do the bootstrap > eglibc and gcc have circular depends and they need several builds before > they provide a useful binary. We won't get rid of that too soon anyway; for the Debian archive, I think it is acceptable to not bootstrap every time. > There are two orthogonal options to build our unstable toolchain > (multiarch or sysroot or sysroot+multiarch). Plus there are three > diferent ways this could be implemented. I'd treat sysroot as something that is only used by the end user, if they want to point their cross gcc at a target installation using CFLAGS. As this target installation could be a Debian like chroot which uses multiarch, we need to support multiarch paths inside a sysroot, and as people want to continue using stuff installed into /usr/$target, those traditional paths need to be supported as well (which sysroot doesn't). > a) Cross tools as an output of main Debian source package (as > lenny). Quite good when working with several arches (these share > same code). Some native maintainers, as gcc/binutils would prefer > not having cross builds output from its native package. This would also require lots of coordination in the form of "could you enable a foo targetted build", and generally won't scale well. > b) Cross tools as an output of new source packages build depending on > -source binaries. One source package per component > (eglibc,binutils,gcc-X.Y,linux-libc-dev). Which makes lots of > packages to maintain 4 or 5 (if we add gdb) per architecture and if > we add uclibc and other non-official arches this list of packages > could grown over a 100 source packages. Sounds pretty sane, provided these source packages are not maintained by hand. I think there could be a Very Short Shell Script(tm) that queries apt-cache showsrc and generates the appropriate packages for upload to Debian and emdebian autobuilders -- I think this will be the way to go for architectures already bootstrapped. > c) Cross tools as an output of one source package. Each target > architecture would only have one source package containing all the > components. This way makes it more practical than b) but it means we > need to rebuild all the tools each time one component updates. We *also* need this one, for bootstrapping, and probably generated by the same script. The idea would be to generate the large package (which would essentially only build one libc and the most recent gcc), give that to the autobuilders in addition to the smaller meta packages above. The only package that can be built at this point is the binutils builder package, as the others are missing build dependencies; with binutils built, we can build the "combined" metapackage, which enables building the others. The binaries built from the combined package are then replaced by the ones from the small packages, so the version of the combined package needs to be smaller (easy to achieve by appending a "~bootstrap" to the version number), and after the binaries are replaced, the source vanishes from the archive as well. Due to an interesting bug in NEW handling, this doesn't even require more action from the ftpmasters. > I would like to know if users have any comment on these issues. b) and > c) makes us independent from native maintainers, so if fine with > everybody I might start working on c). With my proposal, c) is an extension to b). Multiarch sort of prohibits c), as the bootstrapped libc would live in an Archictecture: all package named as if it were a dpkg-cross converted package, which is not what we want for target architectures that are also in Debian. Building a "~bootstrap" version as a -foo-cross style package and then replacing it with a metapackage as described above would work though. > About sysroot and multiarch, any comments? We might keep current > layout for some time (without multiarch nor sysroot) as dpkg-cross > does not support sysroot and multiarch is not ready yet. There is no support dpkg-cross could have for sysroot; wishlist bugs for multiarch exist for some time now, but I haven't found the time to make it actually work. Simon -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
