apt pinning (Re: Boot problem after crashed update)
Javier Barroso (javibarroso@gmail.com on 2011-05-12 19:11 +0200):
>
> Other possible solution would be pinning all packages from sid to
> their current version (upgrading glibc with the bug, of course), and
> removing sid from sources.list, and again wait, but this time you
> could upgrade your system. But I'm not sure if you can have a package
> pinned when the version is not in your repositories from sources.list
> (Can anyone clarify this ?)
You can, but with limitations. For non-version pins, apt needs the
release file so that won't work if you remove it from sources.list.
So a pin like this:
package: libc6
pin: version 2.11.*
pin-priority: 900
Will still work without the release file, but
package: libc6
pin: release a=testing
pin-priority: 900
Will not work if there is no "testing" release in the apt cache.
I would suggest for the OP to create staged pins for all suites (see
below). This is what I do on all systems to prevent all hell from
breaking loose when I add the wrong suite in sources.list :)
Of course, simply setting APT::Default-Release is a simpler solution
but it will only work if you stick to a single suite. In this specific
example, setting Default-Release would have prevented libc6 from
upgrading from stable to unstable, but once libc6-2.13 hits testing,
there is nothing preventing apt from installing libc6-2.14 when it
enters unstable.
Hope this is useful to anyone,
Arno
aschuring@neminis:~$ cat /etc/apt/preferences.d/10releases
# Always mark Debian stable as a prime candidate
Package: *
Pin: release o=Debian,a=stable
Pin-Priority: 900
# slightly preferred release: Debian testing
Package: *
Pin: release o=Debian,a=testing
Pin-Priority: 600
# lower priority of unstable, to allow auto-migration to testing
Package: *
Pin: release o=Debian,a=unstable
Pin-Priority: 300
# all other Debian releases: allow upgrades, but low priority
Package: *
Pin: release o=Debian
Pin-Priority: 200
Reply to: