Bug#685215: Apt pinning is broken

[Kernc <kerncece@gmail.com>]

Since I opened this new bug, I'd like to add my specific use case as well:

Naturally, I want my system stable. Perhaps some time into the release
cycle, I want my user apps updated for the sake of new features, so I pull
them from testing. Chromium and Iceweasel, perhaps with more stable
(supposedly) upstream development, I want on the bleeding edge.
Perhaps I want to stay on Gnome 2 before I move to Xfce for good.
Thus, I end with the following apt preferences:

-- /etc/apt/preferences --

Explanation: I want the base of my system stable.
Package: *
Pin: release a=stable
Pin-Priority: 503

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

Package: *
Pin: release a=unstable
Pin-Priority: 501

Explanation: In some apps, I prefer features over stability.
Package: gimp libreoffice pidgin vlc
Pin: release a=testing
Pin-Priority: 505

Explanation: Other apps may be stable by design. Or I don't really care. D:
Package: chromium iceweasel
Pin: release a=unstable
Pin-Priority: 505

Explanation: But under no condition ever install default gnome (3) package.
Package: gnome
Pin: version 3*
Pin-Priority: -1

-- end /etc/apt/preferences --

But hey!, you say, that gimp and pidgin pull a hell of a long dependency
chain from testing as well...

True. But my kernel, my init scripts, daemons, desktop, ... likely all
remain stable.

With above preferences, with all that software initially installed, running
apt-get upgrade, I should end with gimp, libreoffice, pidgin, and vlc from
testing, unstable chromium and iceweasel, and gnome3 (likely with some of
its apps) nowhere to be seen.

Except that that doesn't work because all those package pins have dependencies
in their respective releases and those dependencies aren't pinned highly
enough as well, so, unless packages were initially installed with -t switch,
apt determines upgrade request to be unsolvable.

(BTW, I'd like to report that the external dependency solver called 'apt'
seems to pay no regard to the APT::Solver::Strict-Pinning setting.)

But that's what external dependency solvers are for! Using the above apt
configuration line, I can tell my sophisticated solver (really just a greedy
one) to get dependencies top-down: What it can satisfy from stable, from
stable; what it can't satisfy from stable but can from testing, from testing,
and the remaining from unstable, all according to the specified release pins.

Behold, awe the Debian mixed system, the truly Universal OS that is itself a
multi-level rolling release.



Argument
--------
What you're saying above can be easily achieved with pinning as implemented
now, and a careful use of apt-get command line, namely `-t` switch or
`pkgname/release` parameter.

Counter-argument
----------------
Say package A (from testing) depends on packages B, C, D, E, F, G. The
versions of these dependencies are such that versions of B, C, D, and E
could be satisfied from stable, but F and G need to be from testing as well.
All release pins as in above preferences.
Either:
$ sudo apt-get install A/testing
fails, because F and G are pinned to stable, but those two can't satisfy the
requirement of A. Or:
$ sudo apt-get -t testing install A
works, but it pulls all those packages from testing, possibly and
unnecessarily (!) making the system less stable.
Ergo, to satisfy above "prefer stable, but adapt if needed" requirement, an
external solver (with Strict-Pinning=false) is required to operate on a
working pinning implementation.
(The alternative is to install each dependency separately, which then really
turns the process into a PITA.)