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?

Braiam
  • 35,991
Dan Anderson
  • 123
  • See http://unix.stackexchange.com/q/112157/4671. I should probably add to explain why you can't just pull packages from testing/unstable into stable. – Faheem Mitha Feb 11 '14 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. – Dan Anderson Feb 11 '14 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.

     – Dan Anderson Feb 11 '14 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. – Faheem Mitha Feb 11 '14 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). – Faheem Mitha Feb 11 '14 at 16:09
  • 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 with priorities packages having within the command, but I don't know how to do that. – Faheem Mitha Feb 11 '14 at 16:17
  • I installed with Crunchbang, which by default shoves stable to 995 (hence the setting). I jacked up the pin value for testing after trying it at 50, to see if it would prompt to replace existing packages.

    In any case, priority 50 does cause apt to work as I expected, as using -t switch still reports libav-tools as the newest version, so it is clearly not searching the correct source (I have run an apt-get update, before you ask.

    And thanks for the warning: I know that pulling testing into stable is not (in general) a fantastic idea. However, I understand the risk.

     – Dan Anderson Feb 11 '14 at 16:22
  • I'm surprised that Crunchbang sets stable to 995 by default. Can anyone shed light on this? – Faheem Mitha Feb 11 '14 at 16:30
  • Correction: Crunchbang does not. Stable=500. Not sure how or why stable got repinned to 995, but it's not default. – Dan Anderson Feb 11 '14 at 16:32
  • Dan, check /etc/apt/preferences, and files in the /etc/apt/preferences.d directory. – Faheem Mitha Feb 11 '14 at 16:44

1 Answers1

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.
Faheem Mitha
  • 35,108
  • 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.

     – Dan Anderson Feb 11 '14 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. – Faheem Mitha Feb 11 '14 at 16:31
  • Crunchbang: 995 is NOT default. 500 is. Not sure how/why stable got repinned. – Dan Anderson Feb 11 '14 at 16:38