Hi, On Fri, Jan 15, 2010 at 12:17:40PM +0000, Neil Williams wrote:
> If you're using dpkg-cross only with packages that are not in Debian, > this won't apply. :( Essentially, my use case looks like this: I roll in-house software as Debian packages, currently using a small self-hacked autobuilder that takes all source uploads to the internal reprepro and builds them for a configured set of host architectures, then runs dpkg-cross on the resulting files and uploads both the compilation result and the package from dpkg-cross back to the internal archive. The chroots do not know whether a given build dependency has been converted already, and thus pull in the -*-cross package, which is already prepared by the autobuilder. If I use dpkg-cross on a multi-arch in-house package without first listing the package in the multi-arch package list, then the resulting -cross binary package is missing all the library files, and the include files all live in /usr/triplet/include/triplet, so that package is unusable. If I do list the input package, then the output package is empty, and does not pull in the real package. > When dpkg-cross builds a -cross package, it then needs to know which > -cross packages from the dependency list are real ones and which are > empty ones. (Not all of these are necessarily installed already.) > 1. Absolute and total reliance on the accuracy of the config file(s) > created, updated and maintained by a separate process, e.g. > update-multiarch.pl from apt-cross (new helper). (If you need two > configurations, use one or more chroots.) Since we have empty dummy packages, it would be acceptable to depend on a dummy instead of a real package, provided the dummy pulls in the real package. This makes the transition a lot easier, as we can convert packages for multiple different suites on the same system by simply giving only the intersection of individual suites' multiarch compliance lists to dpkg-cross (that is, we'd err on the side of generating extra dummy packages and dependencies on them). > 2. If the binary package name being handled by dpkg-cross exists in > that config file, create a multiarch-cross version - if not, behave > precisely as now. It would be good to instead look at the package's Multi-Arch field, and use the list only for dependencies; that way, we don't risk generating a broken package if the list hasn't been updated to add the package being currently processed. > 3. multiarch-cross versions have NO files in the package of any kind. > 4. multiarch-cross versions have a mangled description indicating a > dummy package Good. > 5. multiarch-cross versions depend on the multiarch native package, > i.e. libfoo-ARCH-cross depends on libfoo at or greater than the > version of libfoo that first includes multiarch support. That isn't the case currently, as far as I can see; the generated package is still Architecture: all and has no dependency on the input package. The generated package would need to have the same architecture as the input, a dependency on the input, and a "Multi-Arch: foreign" field to allow it to satisfy dependencies. > 6. multiarch-cross versions include a new control field: > X-Multiarch: delete > 7. multiarch-cross versions have exactly the same package name as now, > e.g. libfoo-armel-cross, to avoid disturbing reverse dependencies. Good. Another possible issue I see are -dev packages that are Architecture: all (such as libasio-dev), i.e. header-only libraries. In principle, we could treat those like multiarch packages if the cross compilers were to look into /usr/include (which they currently don't). With multiarch fully enabled in dpkg, I think we cannot avoid changing the cross compilers here (as the -dev package will always satisfy a build dependency), which will also make sysroot support a lot easier (as the include path now becomes $sysroot/usr/include/$triplet $sysroot/usr/$triplet/include (transition only) $sysroot/usr/include regardless of whether $sysroot is / or something else. The downside to this is that cross compiles will find native headers, but I cannot see how to avoid that at all. Simon -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
