Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4.5 2017-01-19T14:59:38Z 2017-01-19T14:59:38Z David Kalnischkies david@kalnischkies.de 2017-01-19T14:14:19Z urn:sha1:93cff633a830e222693fc0f3d78e6e534d1126ee Most of them in (old) code comments. The two instances of user visible string changes the po files of the manpages are fixed up as well. Gbp-Dch: Ignore Reported-By: spellintian 2016-07-22T14:05:09Z David Kalnischkies david@kalnischkies.de 2016-07-20T16:09:46Z urn:sha1:e5c3f3ccd98e926b91693d961db4d338fd144301 The existing cleanup was happening only for packages which had a status change (install -> uninstalled) which is the most frequent but no the only case – you can e.g. set autobits explicitly with apt-mark. This would leave stanzas in the states file declaring a package to be manually installed – which is the default value for a package not listed at all, so we can just as well drop it from the file. 2016-07-01T08:06:53Z David Kalnischkies david@kalnischkies.de 2016-07-01T08:06:53Z urn:sha1:a0ed43f7323b9d7976ed0ba8d437a42e24af9eaf Traditionally all providers are protected providing something as apt can't know which of them is actually really providing the functionality for the user ensuring that we don't propose the removal of used stuff, but that is of course also keeping stuff around which could be removed. That can cause the collection of multiple old providers until the provided package is itself no longer needed (e.g. out-of-tree kernel modules). We combat this by marking providers only from the newest source package version so that old providers built by older versions of the same source package can be garbage collected. 2016-06-30T16:57:58Z David Kalnischkies david@kalnischkies.de 2016-04-09T11:30:59Z urn:sha1:5a3339db48479114a0e1e11ebc8d640eb3e49933 As the previous commit, this shouldn't change behavior at all, but beside being more explicit and perhaps faster its also considerably shorter (granted, mostly by if0-block elimination). Gbp-Dch: Ignore 2016-06-30T16:57:49Z David Kalnischkies david@kalnischkies.de 2016-04-08T11:03:05Z urn:sha1:769e9f3ea1cbe67d3b98e6db6c956abde2384868 Piling everything in a single if statement always made my head wobble, but it hasn't even a benefit as the most common case of a package which isn't installed passes all of the old if and lands in the non-existent else-part of the inner if. So beside a subjective cleanup of what goes on this implementation should also be a bit faster. No change in behavior should be present. Gbp-Dch: Ignore 2016-06-29T13:01:39Z David Kalnischkies david@kalnischkies.de 2016-06-29T12:57:00Z urn:sha1:520931867ee2fac8415a624204414d3b62550996 If we can't read the old file we can't just move forward as that would discard potentially discard old data (especially other fields). We let it fail only after we are done writing the new file so a user has the chance to look into and merge the new data (which is otherwise discarded). 2016-04-28T08:08:32Z David Kalnischkies david@kalnischkies.de 2016-04-28T07:22:55Z urn:sha1:84573326f41dd09b914b8374548e7ee7c93d0439 The old prettyprinters have only access to the struct they pretty print, which isn't enough usually as we want to know for a package also a bit of state information like which version is the candidate. We therefore need to pull the DepCache into context and hence use a temporary struct which is printed instead of the iterator itself. 2016-04-28T08:08:32Z David Kalnischkies david@kalnischkies.de 2016-04-27T17:39:02Z urn:sha1:91414dd77ec7efe1d3fc053e32cbe4d82263e015 Using Pkg.CandVersion() here is wrong as its implementation will return a candidate based just on the default policy settings ignoring user preferences and otherwise set candidates (aka: it sidesteps the pkgDepCache). This causes M-A:same libraries to be detected as screwed even through they aren't, so that they end up being kept back. Reported-By: Felipe Sateler on IRC 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