Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.2.11 2016-04-25T13:24:44Z 2016-04-25T13:24:44Z Julian Andres Klode jak@debian.org 2016-04-25T13:24:02Z urn:sha1:4ad57118a8a0225b413de96dedc085e0594726a6 2016-04-14T20:21:53Z David Kalnischkies david@kalnischkies.de 2016-04-14T20:02:07Z urn:sha1:b58047e0d8fa8e7d5adca2a24f2ca3ba2596e0ad Tested via (newly) empty index files, but effects also files dropped from the repository or an otherwise changed repository config. 2016-04-14T19:56:01Z David Kalnischkies david@kalnischkies.de 2016-04-14T15:32:17Z urn:sha1:b2fd852459a6b9234255644730f48f071ccad64d There is just no point in taking the time to acquire empty files – especially as it will be tiny non-empty compressed files usually. 2016-04-14T14:55:35Z David Kalnischkies david@kalnischkies.de 2016-04-14T14:16:06Z urn:sha1:479f6fa454cd6ee9e1bc4d9ecda856d34584092e With the previous fix for file applied we can again hit repositories which contain uncompressed empty files, which since the introduction of the central store: method wasn't accounted for anymore as we forbid empty compressed files. 2016-04-14T14:15:39Z David Kalnischkies david@kalnischkies.de 2016-04-14T14:01:56Z urn:sha1:e169fa4a85e03b2b03bb1bdba716b96654ae6050 A silly of-by-one error in the stripping of the extension to check for the uncompressed filename broken in an attempt to support all compressions in commit a09f6eb8fc67cd2d836019f448f18580396185e5. Fixing this highlights also mistakes in the handling of the Alt-Filename in libapt which would cause apt to remove the file from the repository (if root has the needed rights – aka the disk isn't readonly or similar) 2016-04-13T19:33:32Z David Kalnischkies david@kalnischkies.de 2016-04-13T14:24:12Z urn:sha1:c75e60ebb6bc7a578b57e7c4e01579798bae720b Regression introduced in commit 590f1923121815b36ef889033c1c416a23cbe9a2 (2011!) causing apt to not check if Pre-Depends are satisfied before calling --configure. This managed to hide so perfectly well for years as Pre-Depends aren't that common, apt prefers upgrading these packages first and checks for satisfaction is already in SmartUnpack, so there is only a small window of oppertunity to break a pre-dependency relation (usually with an unpack). Verified by logchecking with two provided status files in the buglog. I would have liked to write a test, but I wasn't able to reach the needed complexity to get apt to fail – but the change is small and reasonable, so what could possible go wrong™, right? LP: #1569099 2016-04-13T19:33:32Z David Kalnischkies david@kalnischkies.de 2016-04-13T13:28:33Z urn:sha1:f41352ade22b159c0057f45bcc656dd893d5e74a It handy to be able to point apt at reading a compressed dpkg/status file in debugging cases, which worked pre-1.1 but somewhere down the line in the massive refactoring. Restoring this behavior in a central place for all realfile index files instead of just for the status file. (This has no effect on index files acquired from an archive – those are handled by different classes and support compressed files just fine) 2016-04-13T19:33:32Z Kelemen Gábor kelemeng@ubuntu.com 2016-04-11T06:36:58Z urn:sha1:b04f17c269c7177151396e0471701de3a25ff5a1 Closes: 820638 2016-04-13T19:33:32Z David Kalnischkies david@kalnischkies.de 2016-04-08T10:50:08Z urn:sha1:40703260cdb40409e930a53a04a4061cf2173f42 There is a good chance that the attempt will fail, but if a user mentions certain packages explicitly on the commandline there is a chance that this will consist of a broken system which is resolved by upgrading more packages then just the mentioned. This limitation was not effecting external resolvers. 2016-04-13T19:33:32Z David Kalnischkies david@kalnischkies.de 2016-04-06T14:00:11Z urn:sha1:c1e7b36400db49d3dcb403512e9b009d1b6d05bc Breaking here lets our handler die which a client will fix by reconnecting… but that eats time needlessly and is simple the wrong handling, too. Git-Dch: Ignore