On Sat, 2010-06-19 at 10:24 +0200, Dimitris Lampridis wrote: > On Saturday 19 June 2010 05:27:28 Ross Boylan wrote: > > On Fri, 2010-06-18 at 14:57 +0200, Dimitris Lampridis wrote: > > > I was about to suggest something similar: > > > > > > 1) Add the deb-src for debian testing in your sources.list > > > 2) apt-get update > > > 3) apt-get source mpich2 > > > 4) apt-get build-dep mpich2 > > > 5) cd mpich2-1.2.1.1 (or whatever the name of the created folder) > > > 6) dpkg-buildpackage -uc -us > > > 7) cd .. > > > 8) dpkg -i *.deb > > > > I think there is a catch at step 4 (different from the one already > > mentioned). apt-get build-dep foo operates on the install binary > > package foo. I think if mpich2 is not installed it won't work, and if > > it is installed you will get the dependencies of that version (i.e., > > stable) rather than the one you want to build (unstable). > > > You don't need to have already installed the package you are running apt-get > build-dep against. Why would you anyway? I don't see any reason for such a > restriction. Perhaps someone who knows can comment. apt-get build-dep obviously needs to have the source package control file to work; if it's not on your machine, or if several versions are available, things could go wrong. I recall in my experience that they do, though maybe I'm recalling simply my anticipation of a problem.
> > Regarding what you say about the versions, I thought that that was the point > of backporting: build a newer package against your older libraries. The build dependencies of different versions may differ; if you want the newer version, you need its build dependencies. These may include packages that weren't even listed as build dep of prior versions. You can attempt to use the earlier versions of libraries, but it may not work. There are 3 possibilities for differences in build-dep between versions 1. whether or not a package is mentioned 2. exact version of a package required 3. related packages with different names (version numbers embedded in package name). Each scenario raises different issues. My understanding of 2 is that the control file is not supposed to bump the required version unless it's necessary, and so earlier versions won't work. I don't think packagers follow that rule uniformly, and so an earlier version might be fine. So the degree to which you can fall back to earlier versions of dependencies varies: sometimes you're fine (that is, all the build-deps of the unstable version are also available in stable), sometimes not. > > And if that means that some dependency does not exist in your pool of > available packages, then you have to backport that as well prior to > backporting the final app (mpich2 in this case). Yes. That's why combining versions can get messy fast. > > Having said that, it seems that the --target-release (or simply -t) of > apt-get > could do what you ask, although I have never tried it myself with build-dep. Interesting idea. Ross -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
