Hi, > > 2. Continue discussion on how xcontrol support can actually be > > implemented. Check how it is used in the CodeAudit and tie that into > > the developments at DebConf9.
xcontrol is dead, long live xcontrol. In Cáceres, I had a (long) talk with Guillem Jover from the dpkg team. In general, we both want to get rid of the xcontrol file in the long run, and have the same information provided in the regular control file. There was a small multi-arch cabal meeting, where Wookey, Héctor and myself presented the emdebian use cases (cross compiling and toolchain bootstrap), which led to a small syntax change (as to not close doors) and a request to write a proper paper on what needs to be added to multiarch to support cross-compiling and toolchain bootstrap. Multiarch in general allows us to install packages for any architecture on a single host, provided they do not have file conflicts (with some exceptions) and the version numbers of a single package is the same across all architectures. The file conflicts are avoided by moving all libraries (and for cross compiling, we only care about these) into subdirectories of the respective .../lib directories that are named after the GNU triplet. So, this would allow us to get rid of dpkg-cross (as soon as all libraries are converted to multi-arch). Multiarch also introduces new syntax to relax dependencies. The original plan was to use [same] and [foreign] in the dependency strings (which would introduce these into the architecture namespace, given that square brackets already have a defined meaning for both Depends: and Build-Depends:). This has now been changed to :same and :foreign appended to the package name (e.g. "libc6:same"). There is also a way to specify "all dependencies on this package should be relaxed" so not all packages in the archive need to be touched for multiarch. Our cross-compiling use case is a little stricter than that (i.e. it will probably work for 95% of all packages to assume that all "relaxed" build dependencies are "host" and all "strict" ones are "target" dependencies), but we need a third magic word to specify "although this is a library, we need the host version as a build tool is going to be linked against it". For toolchain bootstraps, we need additional support for "libc6-dev:armel" syntax (once again mixing the namespaces for the multi-arch magic words and architecture names). Multiarch "phase 1" is not going to provide that. General plan: - change cross compilers to look into multiarch include/lib paths - change dpkg-cross to recognize input packages with a multiarch layout - submit a patch to dpkg that allows it to treat our magic word for cross compiling as a "strict" dependency (so it basically does the same thing at runtime that xcontrol now does before upload) - use the CodeAudit database to submit appropriate patches - ??? - Profit > > 5. Get the toolchains back into installable state - I can't upgrade my > > own armel boxes today but I don't have time to investigate why. Build > > scripts that ensure that this persistent problem is fixed for the long > > term and across all supported architectures. This has been discussed in Cáceres as well, and we have a good plan that is not dependent on anything intrusive happening in Debian (i.e. realistic). It is also quite likely that armel cross compilers (at least the most recent version) will end up in Debian proper, as there are packages that build firmware for ARM devices. > > 6. Create a local mirror and use the scripts in emdebian-qa and > > emdebian-tools to upload cross-built packages into the repo and start > > building a small set of packages for armel. Don't proceed to other > > architectures or make the mirror publicly accessible until the rest of > > the issues in the Code Audit have been fixed. Basically, we want an autobuilder that cross-compiles packages and something lintianish to check whether the resulting packages are what we want (specifically, if the generated binaries match the target architecture). > > 8. Start developing ways to test and fix an existing problem in that > > the ./configure scripts in some packages insist on looking for stuff > > in /usr/lib/ and then linking against the shared libraries > > in /usr/arm-linux-gnueabi/lib/ etc. In principle, the configure script should never look at any path directly, but rather trust the compiler. > > 10. test and document the proper support for CC_BUILD in autotools. IIRC the GNU project uses "CC_FOR_BUILD". > > 11. Get Build-Depends split into debian/control and normal Debian? Will happen via an extension to multiarch, but probably not before squeeze. It would be good if we could get at least the "third magic word" into squeeze, so the archive can allow cross-compiling tagged packages after that has been released. > > Possibly as well as Depends-Install (installed on build) and > > Depends-Runtime ? I think it may be more worthwhile to build a special shell that knows how to emulate commonly used commands and push for further adoption of triggers instead of post-installation scripts within Debian. With a bit more effort, we could also run some static analysis on existing packages. > > Mixing Crush and Grip will *only* work if the xcontrol > > support is fixed such that changed functionality is always encoded > > within the binary package name like libgconf-noldap-2-4 etc. This is basically the new use case for xcontrol, once dependencies have moved into multiarch. > > 25. uClibc support I'm currently changing the uClibc package to use multiarch paths. If we can persuade the gcc maintainers to use specs rather than hardcoded paths to find the multiarch directories, making a specs file that allows switching via a single command line parameter becomes really easy, and the horrible hack I use ATM to munge the specs file can die. > > 26. Finalise the cache value support in dpkg-cross and add to it if > > necessary. Consider deploying the cache values into the Debian package > > such that the files can be created at build time on a > > per-package-per-architecture basis. I'd rather fix the configure scripts for good than hack around them. For a lot of packages, simply rebuilding the script with current autoconf is sufficient (for example, current autoconf knows to determine endianness by analyzing the binary with objdump rather than running it). > > 27. Keep an eye on multiarch developments and feed into the process to > > ensure Debian gets a usable cross-build environment based on multiarch. > > Get dpkg-cross merged into dpkg as soon as multiarch is supportable. Outlined above. Simon -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
