apt/apt-pkg/pkgcachegen.cc, branch 1.1.6

add messages to our deprecation warnings in libapt

2015-11-27T14:40:47Z

Git-Dch: Ignore

do not segfault in cache generation on mmap failure

2015-11-19T23:54:07Z

Out of memory and similar circumstanzas could cause MMap::Map to fail and especially the mmap/malloc calls in it. With some additional checking we can avoid segfaults and similar in such situations – at least in theory as if this is a real out of memory everything we do to handle the error could just as well run into a memory problem as well… But at least in theory (if MMap::Map is made to fail always) we can deal with it so good that a user actually never sees a failure (as the cache it tries to load with it fails and is discarded, so that DynamicMMap takes over and a new one is build) instead of segfaulting. Closes: 803417

apply various suggestions made by cppcheck

2015-11-05T11:21:33Z

Reported-By: cppcheck Git-Dch: Ignore

do not ignore differently versioned self-provides

2015-09-14T13:22:19Z

Reported-By: Konomi on IRC

avoid using global PendingError to avoid failing too often too soon

2015-09-14T13:22:18Z

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.

implement dpkgs vision of interpreting pkg: dependencies

2015-09-14T13:22:18Z

How the Multi-Arch field and pkg: dependencies interact was discussed at DebConf15 in the "MultiArch BoF". dpkg and apt (among other tools like dose) had a different interpretation in certain scenarios which we resolved by agreeing on dpkg view – and this commit realizes this agreement in code. As was the case so far libapt sticks to the idea of trying to hide MultiArch as much as possible from individual frontends and instead translates it to good old SingleArch. There are certainly situations which can be improved in frontends if they know that MultiArch is upon them, but these are improvements – not necessary changes needed to unbreak a frontend. The implementation idea is simple: If we parse a dependency on foo:amd64 the dependency is formed on a package 'foo:amd64' of arch 'any'. This package is provided by package 'foo' of arch 'amd64', but not by 'foo' of arch 'i386'. Both of those foo packages provide each other through (assuming foo is M-A:foreign) to allow a dependency on 'foo' to be satisfied by either foo of amd64 or i386. Packages can also declare to provide 'foo:amd64' which is translated to providing 'foo:amd64:any' as well. This indirection over provides was chosen as the alternative would be to teach dependency resolvers how to deal with architecture specific dependencies – which violates the design idea of avoiding resolver changes, especially as architecture-specific dependencies are a cornercase with quite a few subtil rules. Handling it all over versioned provides as we already did for M-A in general seems much simpler as it just works for them. This switch to :any has actually a "surprising" benefit as well: Even frontends showing a package name via .Name() [which doesn't show the architecture] will display the "architecture" for dependencies in which it was explicitely requested, while we will not show the 'strange' :any arch in FullName(true) [= pretty-print] either. Before you had to specialcase these and by default you wouldn't get these details shown. The only identifiable disadvantage is that this complicates error reporting and handling. apt-get's ShowBroken has existing problems with virtual packages [it just shows the name without any reason], so that has to be worked on eventually. The other case is that detecting if a package is completely unknown or if it was at least referenced somewhere needs to acount for this "split" – not that it makes a practical difference which error is shown… but its one of the improvements possible.

ignore AllowMem parameter in cache generation

2015-08-27T09:27:44Z

The parameter name suggests that it should forbid the building of the entire cache in memory, but this isn't how it was previously and as AllowMem is false by default it actually prevents previous usecases from working like being root and configuring apt to build no caches at all. This should be fixed at some point to actually work, but that is hard to pull off as it means switching the default and some callers (including apt itself) actually did call it explicitly with false in certain cases for no apparent reason (at least now where it is common to have enough memory to throw at every problem and even if not is a slow apt usally better than an apt erroring out). Closes: 796459

Fix more instances of missing remapping handling

2015-08-27T09:05:28Z

After fixing Bug#796999, we noticed that there were some more instances of iterators which had no associated Dynamic object, causing them to not be updated when the cache was remapped. This happened in two places: In NewPackage() and in NewProvidesAllArch(). Gbp-Dch: ignore

pkgcachegen: Account for remapping when parsing depends from NewPackage

2015-08-27T09:05:12Z

In both the Ver and Dep variables, we need to account for remapping, as otherwise we would still reference the old bug. Reproduction environment: * An i386 system with amd64 foreign architecture * A sources.list with deb http://snapshot.debian.org/archive/debian/20150826T102846Z/ unstable main deb http://snapshot.debian.org/archive/debian/20150826T102846Z/ experimental main Thanks: Jakub Wilk for the bug report and the backtraces Closes: #796999

Cleanup includes after running iwyu

2015-08-17T10:01:45Z