For each entry (stable, testing, unstable) you have pin-priority 500. You shouldn't use pin > 1000. I use 1001 only when I want to downgrade something. I have testing+sid+experimental entries specified in /etc/apt/sources.list
and the following /etc/apt/preferences
file:
Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 900
Package: *
Pin: release o=Debian,a=experimental
Pin-Priority: 130
The value 500 is default for unstable. So, let's try to check iceweasel:
# apt-cache policy iceweasel
iceweasel:
Installed: (none)
Candidate: 17.0.10esr-1~deb7u1
Version table:
26.0-1 0
130 http://ftp.pl.debian.org/debian/ experimental/main amd64 Packages
24.2.0esr-1 0
500 http://ftp.pl.debian.org/debian/ sid/main amd64 Packages
17.0.10esr-1~deb7u1 0
900 http://ftp.pl.debian.org/debian/ testing/main amd64 Packages
So, if I tried to install iceweasel, it would be downloaded from the testing branch because it has the highest priority.
Try to change the priorities to:
Package: *
Pin: release a=wheezy
Pin-Priority: 900
Package: kpcli
Pin: release a=jessie
Pin-Priority: 910
You could use dpkg-checkbuilddeps
. The man page says
This program checks the installed packages in the system against the
build dependencies and build conflicts listed in the control file. If
any
are not met, it displays them and exits with a nonzero return code.
For example:
faheem@orwell:/usr/local/src/julia/julia-0.3.2$ dpkg-checkbuilddeps
dpkg-checkbuilddeps: Unmet build dependencies: libopenblas-dev (>= 0.2.10-1~) libopenlibm-dev libopenspecfun-dev (>= 0.4~) patchelf python-sphinx-rtd-theme
However, you could also just try building the package, using (for example) debuild
, e.g.
faheem@orwell:/usr/local/src/julia/julia-0.3.2$ debuild -uc -us
dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: source package julia
dpkg-buildpackage: source version 0.3.2-1
dpkg-buildpackage: source changed by Sébastien Villemot <sebastien@debian.org>
dpkg-source --before-build julia-0.3.2
dpkg-buildpackage: host architecture amd64
dpkg-checkbuilddeps: Unmet build dependencies: libopenblas-dev (>= 0.2.10-1~) libopenlibm-dev libopenspecfun-dev (>= 0.4~) patchelf python-sphinx-rtd-theme
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
debuild: fatal error at line 1357:
dpkg-buildpackage -rfakeroot -D -us -uc failed
Which gives the same information (since it uses dpkg-checkbuilddeps
), but is a little noisier.
Best Answer
(If you have questions/comments about this answer, please add a comment. Or, if you have sufficient rep, you can ping me in chat.)
Directly installing binary packages from a newer version of Debian - not the answer.
Suppose you are running some version of a Debian-based distribution. You want a more recent version of a package than is available to you. The first thing that every beginner tries to do it to install the binary package directly on your version of Debian. This may or not work, depending on what version you are running, and how much newer the package is. In general, this procedure will not work well.
Consider for example the case where one is trying to install a binary package from testing/unstable directly on stable. This will most likely not go well, unless testing/unstable happen to very close to stable at that moment. The reason has to do with the nature of a Linux-based binary distribution like Debian. Such operating systems depend heavily on shared libraries, and these dependencies are often very tightly version-dependent; often much more so than necessary. Debian currently does not have a good way of making version dependencies "tight" - a shorthand way of saying that the version dependency is exactly as restrictive as necessary.
What does this mean for the user? Suppose for example that you are trying to install say
slrn
from Debian unstable to Debian stable. What would this look like?Despite the error produced by
apt
, there are no broken packages here. So, what went wrong? The problem is that the version oflibc6
that the unstableslrn
was compiled against is different (and has a higher version number) than the one available on Debian stable. (libc6
is the GNU C library. The C library is central to any Unix-like operating system, and GNU C library is the version that Linux-based operating systems generally use.)Therefore the unstable
slrn
requires a higher numbered version oflibc6
than is available for stable. Note that because a package has been compiled against a higher version of library does not necessarily require a higher version of that library, but it is often the case.The syntax
means: use the unstable
slrn
but for all other packages only use the versions from stable. To be more precise, it uses priority numbers. Seeman apt_preferences
for details.One can also do
This is much more likely to work, but you generally don't want to do it. Why?
This means: temporarily treat all packages in unstable on an equal footing with the packages in stable. Therefore this will pull in the unstable
slrn
's dependencies from unstable if they are of a higher version number, and they generally will be. This will generally include the GNU C library for reasons already explained. Now, this approach will generally "succeed", in that the dependencies will be satisfied by definition (unstable'sslrn
has dependencies which are satisfied in unstable), but you end up with a mixture of packages that suddenly are being forced to run with versions of libraries different from what they were built for. This will probably not end well.The answer is... BACKPORTS!
So, what is the correct way to do this? It is to rebuild the Debian sources of more recent versions on your system, popularly known as "backporting". Consider the following cases:
The first place to look is Debian Backports, which is the official site for Debian backports.
For a concrete example:
Add the appropriate backports line for your release and update to find the new packages then install something from backports explicitly (because backports are deactivated by default).
This will get the latest stable version of git which has useful newer features than the stable one included with stretch (e.g. 'include' which allows you to combine multiple config files or change your username for ~/work/projects/ vs ~/personal/projects/).
Another place to look at is the various PPAs by Ubuntu maintainers. You can do a search for "packagename PPA".
Backporting means that you rebuild the Debian sources from a later version of Debian on the version you are running. This procedure may be easy or involved and difficult depending on the package. Here is an outline of how to do this.
A Brief Backporting Tutorial for Beginners
For concreteness I will assume you are running the current Debian stable, currently wheezy. I'll use the package
slrn
as an example.First, note that all the Debian packaging files live in the
debian/
subdirectory of the source directory.The first step is to check whether a more recent version is available. You can do this using
apt-cache policy
.We would like to backport
1.0.1-10
.STEP 1:
NB: Make sure that the
deb-src
lines for the source version you want to download appears in your/etc/apt/sources.list
. For example, if you want to download the unstable version ofslrn
, you need thedeb-src
line for unstable, or it won't work. Note that you don't need the correspondingdeb
lines to download the sources, thoughapt-cache policy
uses that information, so if you don't have the correspondingdeb
lines, thenapt-cache policy
won't show you the relevant version(s). If you do have thedeb
lines, don't forget to pin the newer versions using an entry in/etc/apt/preferences
or similar. An entry in/etc/apt/preferences
like this (for unstable) will work, for example.If you add lines in
/etc/apt/sources.list
, don't forget to runapt-get update
afterwards.Download the sources for
slrn
. A good place is/usr/local/src/slrn
.STEP 2:
Change the version number slightly, so as to distinguish your backport from the upstream version. Run
dch --bpo
, which will automatically add an entry to thedebian/changelog
file with an appropriate version number, for exampleSTEP 3:
Attempt to build the sources. If the packages required for the build are not available, then the attempt will fail. Change directory into the source directory. Use
debuild
from thedevtools
package.If the build dependencies are satisfied, then the sources will build and produce some debs at the level above the source directory; in this case
/usr/local/src/slrn
.STEP 4:
Suppose the build dependencies are not satisfied. Then you need to try to install the build dependencies. This may or may not work, as the dependencies may not be available for your version, or if available, may not be available in the right version.
NB: It is unfortunately not uncommon for Debian packages to require versions of build dependencies that are higher than necessary. There is no automated way in Debian to check this, and often package maintainers don't care as long as it works on the corresponding version/release. Therefore, take a skeptical attitude to dependency versions, and use common sense. For example, widely used packages like Python and the GNU tools will not depend on very specific versions of their dependencies, regardless what the Debian packager lists.
In any case, you can try to install them doing
If this succeeds, then try building the package again (STEP 2). If it fails, then further work is needed. Note that
debuild
looks at the Build Dependencies in thedebian/control
file, and you can change these if necessary. So let us talk about that now. Here are the Build Dependencies for slrn.An alternative to using
apt-get build-dep
is to install these manually, by doingIf you start changing these values in the control file, then you should switch to a manual installation, as then
apt-get build-dep
will no longer be doing the right thing.In many cases, one can reuse the packaging from earlier versions of the software in conjunction with newer sources. This approach can run into problems, notably patches that applied to earlier versions of the software may not apply here, so one may need to resync them with the sources. The 3.0 (quilt) source format which is now becoming standard uses quilt, and patches are located in the
debian/patches
directory.However, a detailed discussion of these issues is out of scope for this post.