Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1_exp16 2015-11-04T17:04:01Z 2015-11-04T17:04:01Z David Kalnischkies david@kalnischkies.de 2015-10-12T13:57:53Z urn:sha1:14341a7ee1ca3dbcdcdbe10ad19b947ce23d972d The main part is refactoring through to allow hiding the magic needed to support .deb files in deeper layers of libapt so that frontends have less exposure to Debian specific classes like debDebPkgFileIndex. 2015-09-14T13:22:19Z David Kalnischkies david@kalnischkies.de 2015-09-14T11:18:29Z urn:sha1:24e8f24e1e94ec3816b0bfc7a05d1c4e3f73248e This changes the semantics of the option (which is renamed too) to be a yes/no value with the special additional value "force" as this allows by-hash to be disabled even if the repository indicates it would be supported and is more in line with our other yes/no options like pdiff which disable themselves if no support can be detected. The feature wasn't documented so far and hasn't reached a (un)stable release yet, so changing it without trying too hard to keep compatibility seems okay. 2015-09-14T13:22:18Z David Kalnischkies david@kalnischkies.de 2015-09-10T17:00:51Z urn:sha1:95278287f4e1eeaf5d96749d6fc9bfc53fb400d0 Our error reporting is historically grown into some kind of mess. A while ago I implemented stacking for the global error which is used in this commit now to wrap calls to functions which do not report (all) errors via return, so that only failures in those calls cause a failure to propergate down the chain rather than failing if anything (potentially totally unrelated) has failed at some point in the past. This way we can avoid stopping the entire acquire process just because a single source produced an error for example. It also means that after the acquire process the cache is generated – even if the acquire process had failures – as we still have the old good data around we can and should generate a cache for (again). There are probably more instances of this hiding, but all these looked like the easiest to work with and fix with reasonable (aka net-positive) effects. 2015-08-30T20:50:55Z David Kalnischkies david@kalnischkies.de 2015-08-30T20:34:28Z urn:sha1:3090ae6972fd0e15767a96708c248f3ab87502f2 Multiple targets downloading the same file is bad™ as it leads us to all sorts of problems like the acquire system breaking or simply a problem of which settings to use for them. Beside that this is most likely a mistake and silently ignoring it doesn't help the user realizing his mistake… On the other hand, we have 'duplicates' which are 'created' by how we create indextargets, so we have to prevent those from being created to but do not emit a warning for them as this is an implementation detail. And then, there is the absolute and most likely user mistake: Having the same target(s) activated in multiple entries. 2015-08-29T10:33:30Z David Kalnischkies david@kalnischkies.de 2015-08-29T10:28:24Z urn:sha1:8dd562a894c2472e3705fe13c212f665b55744a9 Nobody knows what makes the 'unable to optimize loop' warning to appear in the sourceslist minus-options parsing, especially if we use a foreach loop, but we can replace it with some nice c++11 algorithm+lambda usage, which also helps in making even clearer what happens here. And as this would be a lonely change, lets do it for a few more loops as well where I might or might not have seen the warning at some point in time, too. Git-Dch: Ignore 2015-08-27T16:16:50Z David Kalnischkies david@kalnischkies.de 2015-08-27T16:13:00Z urn:sha1:1a3a14ac63b0c4f18de53a7bddcf79d20a5e814f Disabling pdiffs can be useful occasionally, like if you have a fast local mirror where the download doesn't matter, but still want to use it for non-local mirrors. Also, some users might prefer it to only use it for very big indextargets like Contents. 2015-08-19T07:55:21Z Julian Andres Klode jak@debian.org 2015-08-19T07:50:19Z urn:sha1:defe3231c7bafc4d789219a3250be9ccfbc51914 Also support vertical tabs, as isspace() does the same. Closes: #796067 2015-08-11T11:59:15Z Julian Andres Klode jak@debian.org 2015-08-11T09:05:57Z urn:sha1:c9d715346cae0bd53264d7c25d5af79ca6365707 It complained about the previous code: apt-pkg/sourcelist.cc: In destructor ‘pkgSourceList::~pkgSourceList()’: apt-pkg/sourcelist.cc:278:4: warning: cannot optimize loop, the loop counter may overflow [-Wunsafe-loop-optimizations] for (pkgIndexFile * const File : VolatileFiles) ^ There really cannot be an overflow, though. Rewriting it like this seems to fix it. 2015-08-10T15:27:59Z David Kalnischkies david@kalnischkies.de 2015-07-18T16:03:54Z urn:sha1:5465192b9aeb1ccea778950ccf2d1b7b32f2cd91 Sources are usually defined in sources.list (and co) and are pretty stable, but once in a while a frontend might want to add an additional "source" like a local .deb file to install this package (No support for 'real' sources being added this way as this is a multistep process). We had a hack in place to allow apt-get and apt to pull this of for a short while now, but other frontends are either left in the cold by this and/or the code for it looks dirty with FIXMEs plastering it and has on top of this also some problems (like including these 'volatile' sources in the srcpkgcache.bin file). So the biggest part in this commit is actually the rewrite of the cache generation as it is now potentially a three step process. The biggest problem with adding support now through is that this makes a bunch of previously mostly unusable by externs and therefore hidden classes public, so a bit of further tuneing on this now public API is in order… 2015-08-10T15:25:26Z David Kalnischkies david@kalnischkies.de 2015-06-24T17:31:22Z urn:sha1:b0d408547734100bf86781615f546487ecf390d9 Limits which key(s) can be used to sign a repository. Not immensely useful from a security perspective all by itself, but if the user has additional measures in place to confine a repository (like pinning) an attacker who gets the key for such a repository is limited to its potential and can't use the key to sign its attacks for an other (maybe less limited) repository… (yes, this is as weak as it sounds, but having the capability might come in handy for implementing other stuff later).