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.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
