Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1_exp16 2015-11-21T17:15:22Z 2015-11-21T17:15:22Z David Kalnischkies david@kalnischkies.de 2015-11-21T17:15:22Z urn:sha1:90139c7075afb283428d561b81037039bc7ba149 We do not show the architecture as a dedicated field as this is rather technical information, but as packagename it makes sense to show the architecture as other part of apt will refer to it in this way. 2015-11-21T17:04:29Z Justin B Rye justin.byam.rye@gmail.com 2015-11-21T16:50:06Z urn:sha1:d04e44ac8177fc5b70ae0189bb5e437c2502f910 Reference mail: https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html 2015-11-21T12:47:19Z David Kalnischkies david@kalnischkies.de 2015-11-21T12:47:19Z urn:sha1:abd6af5a1ce2c20a5742c5c3182dfadce10367ca In 8d041b4f we made apt figure out based on the last Release file it has if it should request a file or not given that the hashes changed or not. So if we have a last Release file and do a request, do not sent a Last-Modified header as we expect a change so much that a non-change would indeed be an error. The Last-Modified header is therefore at best ignored by the server, so sending it is just wasted effort. In the worst case as time is a fragile thing the server decides against sending us an update with the idea that we already have the latest content, which we know for a fact that we haven't. Given that we sent less information to the server our request is on its own also less identifiable as coming from a returning or new user. The disadvantage is that if we end up getting an old index file after getting a new Release file from another mirror the old mirror will not be able to tell us 'Hit', but instead sends us the complete file we discard, but both lets us end up with the same error class in the end, so the difference isn't big in practice. 2015-11-19T16:56:07Z David Kalnischkies david@kalnischkies.de 2015-11-19T15:19:15Z urn:sha1:6aef1942f441e6e667982b92802907026d8cc7c6 In ce1f3a2c we started warning about failing unlinking, which we consistently do for directories. That isn't a problem as directories usually aren't in the places we do want to clean up – with the potential exeception of "lost+found", so lets ignore it like we ignore our own partial/ subdirectory. Closes: 805424 2015-11-19T16:13:56Z David Kalnischkies david@kalnischkies.de 2015-11-19T15:00:33Z urn:sha1:87d6947d51717e8b0e975d913986161598a7259a Git-Dch: Ignore 2015-11-19T16:13:56Z David Kalnischkies david@kalnischkies.de 2015-11-19T12:28:17Z urn:sha1:bc7a59dded57338e9b5e523726b246dbdd4e0935 space-gapping: '-o option= value' That is a very old feature (straight from 1998), but it is super surprising if you try setting empty values and instead get error messages or a non-empty value as the next parameter is treated as the value – which could have been empty, so if for some reason you need a compatible way of setting an empty value try: '-o option="" ""'. I can only guess that the idea was to support '-o option value', but we survived 17 years without it, we will do fine in the future I guess. Similar is the case for '-t= testing' even through '-t testing' existed before and the code even tried to detect mistakes like '-t= -b' … all gone now. Technically that is as its removing a feature replacing it with another a major interface break. In practice I really hope for my and their sanity that nobody was using this; but if for some reaon you do: Remove the space and be done. I found the patch and the bugreport actually only after the fact, but its reassuring that others are puzzled by this as well and hence a thanks is in perfect order here as the patch is practical identical [expect that this one here adds tests and other bonus items]. Thanks: Daniel Hartwig for initial patch. Closes: 693092 2015-11-19T15:46:29Z David Kalnischkies david@kalnischkies.de 2015-11-18T18:31:40Z urn:sha1:514a25cbcd2babb2a9c4485fc7b9a4256b7f6ff3 In 0940230d we started dropping privileges for file (and a bit later for copy, too) with the intend of uniforming this for all methods. The commit message says that the source will likely fail based on the compressors already – and there isn't much secret in the repository content. After all, after apt has run the update everyone can access the content via apt anyway… There are sources through which worked before which are mostly single-deb (and those with the uncompressed files available). The first one being especially surprising for users maybe, so instead of failing, we make it so that apt detects that it can't access a source as _apt and if so doesn't drop (for all sources!) privileges – but we limit this to file/copy, so the uncompress which might be needed will still fail – but that failed before this regression. We display a notice about this, mostly so that if it still fails (e.g. compressed) the user has some idea what is wrong. Closes: 805069 2015-11-18T10:38:43Z David Kalnischkies david@kalnischkies.de 2015-11-17T12:43:08Z urn:sha1:671a55ba455dcf4e5ce6d86b202761666f54d5c6 Notices are just hints, but if they are printed in tests, they should be expected and if not the test should fail. No current test has this problem, so that is just potential future proving. Git-Dch: Ignore 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-05T00:51:44Z urn:sha1:f01f5d911d6a9731893865bb1ec617c5038add3e This 'ignores' the component Release files you can find in Debian alongside the binary-* directories, which isn't exactly a common usecase, but it worked before, so lets support it again as this isn't worse than a valid Release file which is unsigned. Git-Dch: Ignore 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-04T22:38:40Z urn:sha1:4453cfdcf42f7fe6859bb0fc6b310a2a391bee77 Limit the field length to a char to avoid bogus FF for utf-8 characters with the default length. Closes: 799123