Re: how to do science with amd64 lenny
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
Reply to: