summaryrefslogtreecommitdiff
path: root/apt-pkg/version.cc
diff options
context:
space:
mode:
authorAndreas Cadhalpun <andreas.cadhalpun@googlemail.com>2015-11-29 13:36:28 +0100
committerDavid Kalnischkies <david@kalnischkies.de>2015-11-29 13:36:28 +0100
commit321213f0dcdcdaab04e01663e7a047b261400c9c (patch)
treea460f5b94aef4efab300b2a232dfd6e41ef27d7c /apt-pkg/version.cc
parent90986d4dbbd38e2e89f986d621e301304210452e (diff)
do not override exact targetrelease matches with lesser matches
The relevant testcases are in test/integration/test-apt-get-source. There is a test for #731853 that is supposed to "ensure that apt will pick the higher version number" of 0.0.1 (stable) and 0.1 (stable). However, this works by pure chance, as simply reversing the order of the two insertsource lines makes the test fail. So #731853 isn't really fixed, yet. Actually, that's related to the problem I reported, as the underlying issue for both is the same: In the FindSrc function apt chooses a new 'best hit', if either * there is a target release and it matches the release of the package, * or the version of the package is higher than the last best hit. Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable), in this order. Looking for the version in stable, apt first selects 1.0, because the release matches the target release, but then subsequently selects 2.0, because the version is higher. Looking for the version in unstable, apt first selects 2.0, because the release matches the target release, but then subsequently selects 1.5, because the release also matches the target release. The correct way would be to choose a new 'best hit', if either * there is a target release and it matches the release of the package, * or there is no target release and the version is higher than the last best hit. Closes: 746412 Mail-Reference: <565A604B.7090104@googlemail.com> Mail-Archive: https://lists.debian.org/debian-devel/2015/11/msg00470.html
Diffstat (limited to 'apt-pkg/version.cc')
0 files changed, 0 insertions, 0 deletions