2

Trying to install a newer version of libav-tools from testing to my otherwise debian-stable installation. I have testing in my sources.list and my preferences look like:

Package: *
Pin: release a=stable
Pin-Priority: 995

Package: *
Pin: release a=testing
Pin-Priority: 101

If I understand the wiki correctly, apt-get install pkg/testing will install pkg from testing but won't pull upgrades to satisfy dependencies, whereas apt-get -t testing install pkg/testing should. However...

Output of apt-get -t testing install libav-tools:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
libav-tools is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.

Output of apt-get install libav-tools/testing:

Selected version '6:9.10-2' (Debian:testing [i386]) for 'libav-tools'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libav-tools : Depends: libavcodec54 (>= 6:9.1-1) but it is not going to be installed or
                        libavcodec-extra-54 (>= 6:9.10) but it is not going to be installed
              ... *truncated*
E: Unable to correct problems, you have held broken packages.

Output of apt-get -t testing install libav-tools/testing is the same.

So, it seems that the -t switch, on it's own, is not finding the newest package version, whereas /testing is breaking from the deps. Can someone tell me if this is user error or a bug?

10
  • See unix.stackexchange.com/q/112157/4671. I should probably add to explain why you can't just pull packages from testing/unstable into stable. Feb 11, 2014 at 15:41
  • tell me about it. I've borked more than one system doing exactly this: I'm demo-ing this on a virtbox first. Feb 11, 2014 at 15:43
  • Just read the link: the question stands. I know how to build for source, I'm wondering about the behaviour of apt. Also, besides this being a virtbox, I doubt new AV libraries will push my system into an unusable state. Feb 11, 2014 at 15:51
  • Dan, the point is that the correct thing to do (as I attempt to explain in my answer) is to rebuild the Debian package sources in your stable system. This is popularly termed "backporting". This may not be easily possible, of course. I just added some comments at the beginning of my answer. I'm still expanding it. Anyway, I see your question is about why you aren't getting the expected behavior - I'll take a look at it. Feb 11, 2014 at 16:05
  • Dan, changing the priority number of stable when running stable is generally a big no-no, afaik, and does not really make sense. The typical sorts of numbers you want to be using for testing/unstable are Pin Priority 50, and don't touch the stable numbers. With those values, -t testing and /testing will behave as you expect. Regardless, -t testing is not a great idea in general (unless you really know what you are doing). Feb 11, 2014 at 16:09

1 Answer 1

1

Dan, changing the priority number of stable when running stable is generally a big no-no, afaik, and does not really make sense. The typical sorts of numbers you want to be using for testing/unstable are Pin Priority 50, and you don't want to touch the stable numbers.

I looked at the Wiki page you referenced (you're really better off reading man apt_preferences at least to start with) and nobody there suggests bumping the priority numbers for stable. Or more generally, the system you are running on.

With those values, -t testing and /testing will behave as you expect. Regardless, -t testing is not a great idea in general (unless you really know what you are doing).

If you want a more detailed analysis of what is going on; I think what happens with /testing is that the priority of the package argument(s) are temporarily bumped up (in that command), probably to 500. For -t testing it bumps everything in testing. However, if you have increased the priority of stable beyond 500, this is not going to work as expected. It is possible to analyze it in more detail - it is probably possible to ask apt what priorities packages have within the command, but I don't know how to do that.

Running a quick test - bumping stable to 995 (my testing and unstable remain at 50) supports the above analysis. With 995 -t testing slrn refuses to do anything. With the normal value of 500 it tries to upgrade 232 packages.

Here is the output from the 995 case. The 500 case is too verbose to include here.

apt-get install -t unstable slrn
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 slrn : Depends: libc6 (>= 2.15) but 2.13-38+deb7u1 is to be installed
E: Unable to correct problems, you have held broken packages.
3
  • Yep. This is the write path. I'm looking over man apt_preferences, and -t pushes the target release to 990 (kind of), which is still less than stable. Bumping stable down to 989, should work (DISCLAIMER HERE). I admit, I find apt using a bunch of magic numbers for pins a poor design choice, but hey, that's what the docs are for. Feb 11, 2014 at 16:29
  • Maybe crunchbang has configured 995 to be the new 500, which seems like a weird thing to do, but is certainly possible. These numbers are all arbitary, after all. Feb 11, 2014 at 16:31
  • Crunchbang: 995 is NOT default. 500 is. Not sure how/why stable got repinned. Feb 11, 2014 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.