[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg-cross multiarch transition


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

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


>  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

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.


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/$triplet/include (transition only)

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.


Reply to: