Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.exp11 2015-08-17T16:37:18Z 2015-08-17T16:37:18Z Julian Andres Klode jak@debian.org 2015-08-17T16:37:09Z urn:sha1:e7ebb41440cbe298b07c7fb7c6b20a64a17200f0 Gbp-Dch: ignore 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-16T17:41:45Z urn:sha1:ecc138f858fab61e0b888d3d13854d1422c3432b Expecting the worst is easy to code, but has its disadvantages e.g. by creating package structures which otherwise would have never existed. By creating the provides instead at the time a package structure is added we are well prepared for the introduction of partial architectures, massive amounts of M-A:foreign (and :allowed) and co as far as provides are concerned at least. We have something relatively similar for dependencies already. Many tests are added for both M-A states and the code cleaned to properly support implicit provides for foreign architectures and architectures we 'just' happen to parse. Git-Dch: Ignore 2015-04-18T23:27:31Z David Kalnischkies david@kalnischkies.de 2015-04-18T23:24:46Z urn:sha1:05f64ca2e483709faa6bc69dfa79129d2d4c679e Conflicts: apt-pkg/acquire-item.cc cmdline/apt-key.in methods/https.cc test/integration/test-apt-key test/integration/test-multiarch-foreign 2015-04-12T19:44:27Z David Kalnischkies david@kalnischkies.de 2015-04-12T17:16:01Z urn:sha1:596ec43ce34421080a58b28299c1ed9cb0dbaa25 On single-arch the parsing was creating groupnames like 'apt:amd64' even through it should be 'apt' and a package in it belonging to architecture amd64. The result for foreign architectures was as expected: The dependency isn't satisfiable, but for native architecture it means the wrong package (ala apt:amd64:amd64) is linked so this is also not satisfiable, which is very much not expected. No longer excluding single-arch from this codepath allows the generation of the correct links, which still link to non-exisiting packages for foreign dependencies, but natives link to the expected native package just as if no architecture was given. For negative arch-specific dependencies ala Conflicts this matter was worse as apt will believe there isn't a Conflict to resolve, tricking it into calculating a solution dpkg will refuse. Architecture specific positive dependencies are rare in jessie – the only one in amd64 main is foreign –, negative dependencies do not even exist. Neither class has a native specimen, so no package in jessie is effected by this bug, but it might be interesting for stretch upgrades. This also means the regression potential is very low. Closes: 777760 2015-03-16T17:01:54Z David Kalnischkies david@kalnischkies.de 2015-03-09T23:59:44Z urn:sha1:25b86db159fbc3c043628e285c0c1ef24dec2c6e We use test{success,failure} now all over the place in the framework, so its only consequencial to do this in the situations in which we test for a specific output as well. Git-Dch: Ignore 2011-11-23T08:54:17Z David Kalnischkies kalnischkies@gmail.com 2011-11-23T08:54:17Z urn:sha1:286afa36886b60bea0a17d244f8bddad938f27cf - ignore foreign architectures if we check if a provides has only one resolver as it's basically the same for the user, so no need to choose 2011-11-22T23:49:45Z David Kalnischkies kalnischkies@gmail.com 2011-11-22T23:49:45Z urn:sha1:2b5c35c7bb915dbd46fefd7c79f05364ba22f93b - prefer native providers over foreigns even if the chain is foreign The code preferred real over virtual packages and based on priorities. This is changed in so far that a real package from any arch is preferred over any virtual provider and if priorities doesn't help in choosing the best provider we choose it based on architectures