Package: apt Version: 0.9.7.4 Severity: important Tags: confirmed I took liberty to mark this as confirmed, as it very well is and will as such hopefully jump at the willing contributors from the top of the outstanding bugs list. Maintainers' sympathy kindly appreciated.
I know this is kind of TL;DR, but I don't have a blog, and this is a valid issue report with accompanying observations and proposals. Please bear with me... Facing it now: apt pinning, other than general pinning on release (i.e. "Package: * \n Pin: release..."), is **broken.** Per-package pinning doesn't work intuitively (countless forum posts around, several bug reports below), version pinning suffers serious bugs (doesn't work, doesn't glob() properly [4])... This important bug spans 9 years (since 2003), several directly-related bug reports: [1] http://bugs.debian.org/254820 , [2] http://bugs.debian.org/387218 , [3] http://bugs.debian.org/443565 , [4] http://bugs.debian.org/454080 , [5] http://bugs.debian.org/554773 , [6] http://bugs.debian.org/620249 , several directly-related bug reports that were nonchalantly demoted to wishlist-items (?!) by Matt Zimmerman: [7] http://bugs.debian.org/216688 , [8] http://bugs.debian.org/239247 , [9] http://bugs.debian.org/242738 , [10] http://bugs.debian.org/276602 , [11] http://bugs.debian.org/483147 , [12] http://bugs.debian.org/312589 , and many "apt-cache policy", general pinning and its documentation related bugs: [13] http://bugs.debian.org/166032 , [14] http://bugs.debian.org/308445 , [15] http://bugs.debian.org/301464 , [16] http://bugs.debian.org/405262 , [17] http://bugs.debian.org/557637 , [18] http://bugs.debian.org/602094 , [19] http://bugs.debian.org/623706 , [20] http://bugs.debian.org/673760 . (...) All these (and possibly other, merged) bug reports, and countless forum posts [21] desperately say one thing: ** Fix `apt-pkg/policy.cc` and rewrite documentation pertaining it! ** Let's do it once and for all? I don't know who first 'invented' pinning as implemented now, but she most certainly did it wrong, mainly by making it counter-intuitive. The argument that "just RTFM, the specification is such and is correct," in spite of being unable to satisfy a most common use case —that is, simple package pinning— is a non-argument! The problem lies in assigning priorities. The per-package/version priorities aren't even priorities in the general sense, but rather some kind of minimum priority required, as detailed in Carlo Wood's comprehensive pinning documentation & errata [22], the author of which reported [2]. This limitation is a serious usability issue. Furthermore, one cannot even use an external EDSP/CUDF dependency solver and expect coherent results, with APT::Solver::Strict-Pinning set to "false" or otherwise, since package (or version) pins aren't even properly propagated into EDSP/CUDF dumps, that because policy.cc simply doesn't account for those pins correctly. I kindly ask you to spare the discouragement warnings in this instance: apparently there are valid use cases for pinning ([1-12, 21])! The problematic policy.cc code may be extremely hard to fix if one is not well versed in C++ (which I'm not), especially with so few convenience dependencies, but fuck me if somebody is not up to the challenge. Whoever fixes this does not only get to enjoy a crate of virtual beer (and eternal satisfaction by the houri, acknowledged contribution one can put in her résumé, etc. other immaterial pleasures), but I vow to Flattr/PayPal/Kickstarter $50 myself, and I am only a poor student. Since this is not a release-critical bug, there's enough time for testing until the next freeze. [21] http://www.google.com/search?q=apt+pinning+doesn't+work [22] http://carlo17.home.xs4all.nl/howto/debian.html#errata -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
