Re: Crush 2.0 abandoned
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
Reply to: