Re: The state of cross building
On Tue, Feb 02, 2016 at 11:39:50AM -0500, Theodore Ts'o wrote:
> I see these haven't entered testing because:
>
> * 183 days old (needed 5 days)
> * crossbuild-essential-arm64/amd64 unsatisfiable Depends: libc6-dev:arm64
> * crossbuild-essential-armel/amd64 unsatisfiable Depends: libc6-dev:armel
> * crossbuild-essential-armhf/amd64 unsatisfiable Depends: libc6-dev:armhf
> ....
> * Invalidated by dependency
> * Not considered
> * Depends: build-essential dpkg-cross
>
> Am I right in thinking this is because of how the testing scripts
> work; is this something that is likely to be fixed in the future, or
> is crossbuild-essential-* something that is only intended for unstable
> and never for testing/stable?
As far as I can tell, there is nothing that would make these packages
unfit for release in principle. However, there currently are unsolved
problems that prevent them from transitioning to testing.
The crossbuild-essential-* packages use cross-architecture dependencies.
This is a rarely used feature and it is not currently supported by
britney. Thus these packages cannot transition before britney is
changed. I am not aware of anyone working on this problem. Adding this
feature to britney could also help with #807312.
The crossbuild-essential-* packages depend on dpkg-cross, which
currently is RC-buggy and not part of jessie or stretch and thus also
blocking the migration. The dpkg-cross tool is used to convert
architecture-dependent library packages into architecture-independent
packages for use in a pre-multiarch era. It happens to also contain
config.site files, that provide check results to autotool's configure.
The latter is the reason for this dependency.
It seems like these check results should find a new home, but it is not
clear that keeping them in a central place is a good long-term solution.
It also seems that every cross distribution has its own way of
maintaining these, which is sad. I have some ideas floating for
improving, but I put my work on hold to better understand the
requirements. In order to get a better understanding, I am maintaining
these check results on a per-package granularity for rebootstrap[1].
Personally, I am hoping for a future where packages that are being
checked ship these check results. For example, glibc contains malloc, so
libc6-dev could contain a file expressing
ac_cv_func_malloc_0_nonnull=yes. In a similar vein, acl contains
acl_get_file, so libacl1-dev could express
gl_cv_func_working_acl_get_file=yes. Unfortunately, some packages use
non-canonical names (e.g. xorg_cv_malloc0_returns_null), so the
envisioned future is non-trivial to implement.
You see that the whole cross building story is a huge task. Progress is
slow (but steady) and help is always welcome.
Helmut
[1] https://wiki.debian.org/HelmutGrohne/rebootstrap
Reply to: