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
