On Sun, Nov 29, 2015 at 03:17:47AM +0100, Andreas Cadhalpun wrote: > >> Last = Parse; > >> Offset = Parse->Offset(); > >> Version = Ver; > >> + break; > >> } > >> } > >> > > > > That 'fixes' this problem while reopening #731853 among others. Running > > the autopkgtest tests would have shown it. You can do this without > > building and installing apt packages via ./test/integration/run-tests, > > which will use the apt buildtree it is in. You need to install a bunch > > of additional test-dependencies through. > > Thanks for pointing to the autopkgtests. However, some tests fail with: > "You have to build aptwerbserver or install a webserver" > > But there is no aptwe*r*bserver... > One has to do: > $ cd test/interactive-helper > $ make aptwebserver A simple 'make' in the top-level directory builds this webserver just the same as it builds all the rest of the (apt) world [in fact, it should be the very last thing it does] which is needed in some capacity by the various testcases. That there is an explicit check for the aptwebserver is caused by a) for a while we tried getting real webservers in line, but the simple ones lack HTTP1.1 features and the bigger ones are a giant pain to setup (and do lack features as well) and b) that aptwebserver isn't shipped in a package as Debian doesn't need yet another packaged security-buggy webserver. (aka: going to fix message to reflect reality). > > Adding a testcase here (they are simple shell scripts with an insane > > amount of shell functions building a testing 'framework' to setup > > packages, repositories and webservers among others) wouldn't hurt the > > acceptance of a patch either. > > How sane can a framework be if it has to generate packages that are "used > only by testcases and surf [...]", even though there are no waves? ;) You have never seen apt fail bigtime then. That generates lots of waves… ;) > 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. [you usually do not have this order as Sources tends to be ordered, but you are right that assuming it is wrong.] > 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. > > Attached is a patch fixing this and another one adding above two > testcases. And as a testrun doesn't show regressions… applied & pushed to git. Should be part of the next upload, which might or might not be soon depending on how many RCs people find now to block our transition after they had months in experimental to do it. ;) Thanks for working on this! Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature