On Fri, Jan 18, 2013 at 08:54:26AM +0100, Raphael Hertzog wrote: > On Wed, 16 Jan 2013, Colin Watson wrote: > > This is cleaner than any of the other options I've come up with: it > > doesn't require hardcoding a list of "toolchain packages" that have > > special cross versions; it would allow us to stop having to shove > > pkg-config-HOST into cross-build chroots; and it wouldn't require > > dpkg-checkbuilddeps to violate layers by looking in the apt cache, at > > least as long as the available file is up to date. Does it seem sane to > > people? > > The /var/lib/dpkg/available file is almost never up-to-date unless you use > dselect... so that part doesn't look so sane unless I missed something.
True. Maybe this plan can be rescued, though. Provided that a version of the package is installed, the control field will be present in the status file; so, after you install the build-architecture version, dpkg-checkbuilddeps could look at that and know that it still needs a host-architecture version. Now, this is a bit awkward because you need two passes if you're relying entirely on dpkg-checkbuilddeps rather than on a higher-level tool that can inspect the apt cache; but it's only for cross builds, and dpkg-checkbuilddeps doesn't always print an accurate list of packages to install in any event (e.g. virtual packages). I think that the most important part of its contract is still met as long as it exits zero if and only if all build-dependencies are satisfied, and it would still be able to do that. Does that sound acceptable? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130118131417.ga...@riva.dynamic.greenend.org.uk