Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2.10 2016-03-27T00:09:14Z 2016-03-27T00:09:14Z Julian Andres Klode jak@debian.org 2016-03-26T23:20:05Z urn:sha1:6df5632313e9ce77c47ee4bcf6e32a028c4534d0 If the package is marked for removal, keep it marked for removal and do not mark it for keep. If we mark it for keep, we some how later get to a different stage where it is marked for unpack instead of removal. In the example in the bug report, we would get a: SmartUnPack maas-region-controller-min:amd64 (replace version 2.0.0~alpha3+bzr4810-0ubuntu1 with Segmentation fault maas-region-controller-min:amd64 was marked for removal, but we changed it to keep and somehow it thinks that this is to be replaced now instead of removed (probably because the InstallVer != CandidateVer [with InstallVer = 0]). This fixes a regression introduced in release 1.2.7, commit: 0390edd5452b081f8efcf412f96d535a1d959457 Reported-by: LaMont Jones on IRC LP: #1562402 2016-03-16T22:29:45Z David Kalnischkies david@kalnischkies.de 2016-03-16T21:32:48Z urn:sha1:a38cec81d349525c447004ef8fe9dc942c8bd9bb The epoch stripping in this code is done since day one, but in other places we show a version epochs are not stripped. If epochs are present in packages they tend to be an important information which we can't just drop and especially can't drop "sometimes" as that confuses users and tools alike – so even if removing code in use for (close to) 18 years feels wrong, it is probably the right choice for consistency. Closes: 818162 2016-03-15T17:55:02Z Michael Vogt mvo@ubuntu.com 2016-03-15T12:13:54Z urn:sha1:0390edd5452b081f8efcf412f96d535a1d959457 The problemresolver will set the candidate version for pkg P back to the current version if it encounters an impossible to satisfy critical dependency on P. However it did not set the State of the package back as well which lead to a situation where P is neither in Keep,Install,Upgrade,Delete state. Note that this can not be tested via the traditional sh based framework. I added a python-apt based test for this. LP: #1550741 [jak@debian.org: Make the test not fail if apt_pkg cannot be imported] 2016-01-25T17:15:44Z David Kalnischkies david@kalnischkies.de 2016-01-20T14:49:46Z urn:sha1:529bf9b00dfd3c0472d77e9515007e52a3557bc4 If you have chosen to install a foreign architecture provider it is more reasonable to keep this provider instead of removing this one to replace it with a newer version from a (usually) more preferred arch. Git-Dch: Ignore 2015-11-25T14:20:10Z David Kalnischkies david@kalnischkies.de 2015-11-22T14:09:50Z urn:sha1:add81166f8ecb194ab5cf881200ab9d890abea6c The manpages were fixed by Justin B Rye, lets deal with the rest now. Git-Dch: Ignore 2015-11-04T17:04:05Z David Kalnischkies david@kalnischkies.de 2015-10-30T15:34:25Z urn:sha1:294a80209a0c6ea617a14fb2ae650d4fd329eab5 This was discussed a while ago on #debian-apt and now that I see myself making this mistake lets bite the bullet and fix it in the easy way out version: Using a new name which fits with a similar named setter and deprecate the old method instead of 'hostily' changing API. Closes: #803471 2015-08-17T10:01:45Z Michael Vogt mvo@debian.org 2015-08-17T10:01:45Z urn:sha1:88a8975f156e452d9f3ebe76822b236e8962ebba 2015-08-15T09:54:08Z Julian Andres Klode jak@debian.org 2015-08-15T09:52:50Z urn:sha1:a0a6695515f8d8d7db3f52751d4d14f8266c286c Also unify the case of considerFiles and ConsiderFiles to be ConsiderFiles in all cases. Gbp-Dch: ignore 2015-08-13T09:31:00Z Julian Andres Klode jak@debian.org 2015-08-13T09:28:32Z urn:sha1:98cc7fd2c1d397623960baf69ae3cec04a87a23e More standardization 2015-08-13T09:30:59Z Julian Andres Klode jak@debian.org 2015-08-13T08:43:49Z urn:sha1:47c37a1bfc2f2f372bf057bf68bde0b3b6f0ec8f This is nicer