Re: dpkg-cross multiarch transition
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
Reply to: