Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2.8 2016-03-16T22:29:45Z 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 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-08-10T14:08:21Z urn:sha1:5f4495e342e94a75b17ceed2fa05d689f050df7b oldlibs used to be in APT::Never-MarkAuto-Sections so that old transition packages can be removed without causing the then (autoinstalled) renamed package to be autoremoved. It isn't ideal through as ideally you want the oldlibs package to be removed after nothing depends on it anymore regardless of if you have once installed it by hand or not – and if you had the package talking over (the dependencies) should carry the manual bit now as they are the real deal now. As an added bonus if the package has no dependencies because it is an oldlibs without a direct replacement you should move away from (like lib1 and lib2 are currently in the archive, but there will hopefully only be lib2 in the release) you get a lib1 marked as auto. If the user still needs the oldlibs package for some reason all he has to do is mark it as manual once as this move is only performed if a installed package changes its section from a not-Move-Autobit-Sections to a Move-Autobit-Sections.