On Sat, 22 Oct 2011 14:58:01 -0700 Steve Langasek <vorlon@debian.org> wrote: > 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. :) IIRC the reasoning for the original default was to provide cross-building behaviour post-Multiarch which was the most similar to cross-building behaviour under dpkg-cross, with the fundamental change that the cross-dependencies in Multiarch world would be understood by apt and dpkg. Logically, I still think this should be the long term goal. What I think we're covering here is the interim stages whilst there is this lack of clear direction on the behaviour of -dev packages in Multiarch and a lack of -dev packages with appropriate changes. If we can get packages to work with the long term goal it would make it easier to achieve the goal without having to make the changes twice. > apt accurately implements the behavior requested on > <https://wiki.ubuntu.com/MultiarchCross>, which says that for a package > > 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. Exactly - so in the interim period where there are no clear guidelines yet and no critical mass, do we actually need to change the default or just accept the *result* of these complications? > - 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. The result being, of course, that swapping -dev packages in and out of the build environment is simply not going to happen (because people will generally need to be able to make a bug fix natively, cross-build it quickly and get back to development). Instead "swapping -dev packages in and out of the build environment" simply translates into "requiring cross-builds to happen in chroots" like pbuilder, schroot etc. I think we can specify that without needing to change the default behaviour. Are there reasons why this wouldn't work? Effectively we don't hot-swap build-deps, we just have two build environments. The packages which caused trouble with this in Lenny were GTK and pango which both build native tools which are executed during the build to generate package metadata which is used by the cross-built binaries. There was always a problem here about potentially getting the wrong data because the work was done on the wrong arch and potentially in the wrong directories (due to dpkg-cross). Those problems are fixable but *will* require the build-dependencies of the native tools to be present in the same build environment and at precisely the same time. libglib2.0-dev is one of the most likely here. > - 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. It was always excluding the non-dev dependencies like debhelper and native build dependencies like cmake|automake etc. which caused all the problems with the apt-cross|dpkg-cross partnership. As long as that is working in a way that allows apt to automatically manage upgrades to existing packages (of both architectures), we all win. Upgradability of cross -dev packages is the single biggest gain I need from Multiarch. Proper cross-architecture installation dependency resolution and management. I don't really care if I can't have -dev packages for armel and amd64 in the same build environment initially - as long as that can happen eventually. What I need is for armel build dependency packages to be automatically and easily upgradable in-situ, using apt itself, without the need for secondary tools like apt-cross, xapt etc. i.e. apt-get build-dep -a $arch isn't actually that much of a gain - we can do that without MultiArch being complete. apt-get update -a $arch ;; apt-get dist-upgrade -a $arch is FAR more useful because it is something which has been impossible with dpkg-cross. It worked for small values of "worked" with apt-cross and it just doesn't work at all nicely with xapt. > 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. If we accept that switching -dev packages in and out of a build environment just makes cross-building unnecessarily painful for actual cross architecture development (rather than cross-arch distro preparation) then we have to mandate that until the guidelines for -dev packages are more achievable, that cross-building in MultiArch world is restricted to chroots. If that is accepted, then it doesn't need a change in apt - the chroot can use DEB_BUILD_ARCH in the chroot as easily as it can use DEB_HOST_ARCH, just without needing a change to the default. What have I missed? > 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? If we mandate chroots, until critical mass is achieved, would we still need changes? (I must be missing something somewhere ....) -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpk1q97ovA5r.pgp
Description: PGP signature