Hi, On Thu, 27 Oct 2011, Sven Joachim wrote: > Whether it's multi-arch enabled depends on the debhelper and dpkg-dev > versions on the build system. With debhelper from squeeze-backports and > dpkg-dev from squeeze, ncurses builds fine (without multiarch support, of > course).
Just because dpkg-architecture -qDEB_HOST_MULTIARCH fails... and thus $(DEB_HOST_MULTIARCH) happens to be empty. Is this really something that was made on purpose? To me any usage of DEB_HOST_MULTIARCH should warrant a build-dep on dpkg-dev >= 1.16.0 in theory. (The version of debhelper doesn't matter except to automatically set misc:Pre-Depends AFAIK). > And adding build-dependencies on multiarch-support would be very > unfriendly to backporters. I think that converting a package to multiarch is inherently unfriendly to backports. If you want to support both a traditional build (for backport purpose) and a multiarch build, I think you'd better be explicit about it in debian/rules (use a dedicated variable that you can easily switch) instead of relying on dpkg-architecture -qDEB_HOST_MULTIARCH to fail and thus return an empty string. Adding the multiarch-support dependency on dpkg-dev means that your package would build but would get its multiarch-support pre-dependency too, making it uninstallable in squeeze without upgrading the libc6. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/go/ulule-rh/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
