Bug#646288: apt-get build-dep -a $arch: wrong tradeoff for the default?

Package: apt
Version: 0.8.16~exp5
Severity: wishlist
User: [email protected]
Usertags: multiarch

I've been having lots of fun playing with the 'apt-get build-dep -a $arch'
support added to apt in version 0.8.15.3 (fixing bug #632221).  As I do so,
however, I think we've made a wrong trade-off in terms of the default
behavior for packages.  I've actually thought this for a while, but it's
become enough of a hassle now that I think I need to raise it as a bug and
agitate for getting the behavior changed. :)

apt accurately implements the behavior requested on
<https://wiki.ubuntu.com/MultiarchCross>, which says that for a package
which is Multi-Arch: no, the build-dependency will be satisfied using the
package for the build architecture.  The rationale for this is that, whereas
library -dev packages are likely to be touched anyway in order to make them
Multi-Arch: same, the random other non-library packages that are used as
build dependencies would not otherwise be updated to be marked Multi-Arch:
foreign, so by defaulting to the build-arch packages we can focus on just
getting the -dev packages marked Multi-Arch: same.

This is correct as far as it goes, but there are a number of complications.

 - Unlike marking a package Multi-Arch: foreign, which is just adding
   metadata, converting a -dev package to be Multi-Arch: same is not always
   easy.  There are no best practice guidelines yet for converting a -dev
   package to be Multi-Arch: same when it contains a mix of
   architecture-dependent and architecture-independent headers, so many of
   these -dev packages are not getting converted right now.  Of 696 packages
   that have been tagged Multi-Arch: same in unstable[1], only 74 of them
   are -dev packages.  Since some of the affected packages are pretty low in
   the dependency tree, this effectively stops us from reaching critical
   mass of cross-build-friendly multiarch -dev packages.

 - Whereas cross-installability of -dev packages is a must for
   cross-building, for the vast majority of libraries, *co*installability is
   merely a nice to have.  There are very few libraries that you need to
   build against both the host and build versions of as part of a single
   package build; so while it's inconvenient to have to swap -dev packages
   out in a build environment when switching target architectures, it's
   tolerable... especially since it would enable uses that aren't possible
   today.  Only the apt implementation makes M-A: same a requirement.

 - There are a lot more library -dev packages as build-dependencies than
   there are non-dev packages as build-dependencies, at least for the cases
   that are interesting for cross-compilation.  If we ignore
   build-dependencies on python, java, ruby, perl, gir, haskell, and erlang
   packages[3], approximately[4] 60% of all build-dependencies are on
   library -dev packages; and of the ones that are not -dev packages, there
   are already more Multi-Arch tags set in the archive (91) than there are
   on the -dev packages[5]!  This implies to me that many of these packages
   will be marked Multi-Arch: foreign anyway because the tag is needed for
   runtime.

So for the above reasons I think it would be better for apt-get build-dep to
require the DEB_HOST_ARCH package for M-A: no build-depends.

Cc:ed to multiarch-devel and debian-embedded for comments.  Since this
proposal implies pushing more patches to packages to make them Multi-Arch:
foreign, perhaps this should be discussed on debian-devel to get a consensus
there?

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
[email protected]                                     [email protected]

[1] grep-dctrl  -FMulti-Arch same /var/lib/apt/lists/_mirror_dists_sid_main_binary-amd64_Packages \
    | grep -c Package
[2] grep-dctrl  -FMulti-Arch same /var/lib/apt/lists/_mirror_dists_sid_main_binary-amd64_Packages \
    | grep -c Package.*-dev
[3] grep-dctrl -sBuild-Depends -r '.' -n /var/lib/apt/lists/debian.osuosl.org_debian_dists_sid_main_source_Sources \
    | sed -e's/([^)]\+)//g; s/\[[^]]\+\]//g; s/[,|]//g; s/ \+/\n/g' | sort -u \
    | grep -vE 'python|java|ruby|-perl|^gir|^libghc|haskell|erlang'
[4] "approximately" - because included in this count are some packages like
    x11proto-dev packages, which are Arch: all (and Multi-Arch: foreign),
    and a few packages like autotools-dev which aren't headers/libs at all
[5] grep-dctrl -sBuild-Depends -r '.' -n /var/lib/apt/lists/debian.osuosl.org_debian_dists_sid_main_source_Sources \
    | sed -e's/([^)]\+)//g; s/\[[^]]\+\]//g; s/[,|]//g; s/ \+/\n/g' | sort -u \
    | grep -vE 'python|java|ruby|-perl|^gir|^libghc|haskell|erlang' \
    | grep -v -- -dev | xargs apt-cache show |grep -c Multi-Arch

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIVAwUBTqM8aVaNMPMhshM9AQgylQ//cH/q1DRV4fSty9OymLbrJXepDjpwscoq
rYqShCra7+CQBIqk070HiqLS0ZA601Kk58u/bXxo6lnDas5RhICy0pcFvKqbnSyX
P9GAglANnDKidHWxvkJpVcxI6b1FlNttACOGNSdQV2+hi2mNALPGVT8x/cvIPiop
SFdkEGQkeCvgcbRJTiKFreBUSmmbq5GafmZ1c6wwdAEF+qCQTce1sfXQeodS9tcK
AKV62Kf1o1HW/qxtO84Or5RdR8+UCE4tsx0MPOooVfP2rmoyRH2KKRvh5i8phvnn
LLePBFLUzEMAjIJ+Rh81eR9pFqpceMcg3OWDBnc0ror7T5wwZcn4v9exY/BNhfdJ
bjiNb272DQSdfRrAzv9PRRnbbIwtbRpy246J0eKnCJktLPVpCrAReLv+cMLP/52M
9WftLMJ0q2ie+2Lw/Qvsmcx3G4wqNHOSWygH5l+0uF1E0aaTT+jhwsby5WhYmFSE
lR3VjXdpQbUYMmBuqIRrAxXRotLlAy4njE2WO0etwJF8GM9v3ZahrcY3RGkdJARg
HUTJgHsqfFAfkqgz/ZN0HsDKfgeLVnVrqJdQ68sPLElqWOeM52EVYs3HpuMdYG+q
+PUlJulF3cu8y+ykWf0iqsTyytWM+AYQ+xehOcViMXgdy3rBywfgtdeSr957RIGm
SaYgo9T95a0=
=Y0Ei
-----END PGP SIGNATURE-----