apt/apt-pkg/depcache.cc, branch 1.1.2

typo: run s#frontend#front-end# on all of src:apt

2015-11-25T14:20:10Z

The manpages were fixed by Justin B Rye, lets deal with the rest now. Git-Dch: Ignore

sanify API to get 'the' candidate version

2015-11-04T17:04:05Z

This was discussed a while ago on #debian-apt and now that I see myself making this mistake lets bite the bullet and fix it in the easy way out version: Using a new name which fits with a similar named setter and deprecate the old method instead of 'hostily' changing API. Closes: #803471

Cleanup includes after running iwyu

2015-08-17T10:01:45Z

Add GetPriority(VerIterator) to pkgDepCache::Policy

2015-08-15T09:54:08Z

Also unify the case of considerFiles and ConsiderFiles to be ConsiderFiles in all cases. Gbp-Dch: ignore

Deprecate SPtrArray and convert everyone to unique_ptr

2015-08-13T09:31:00Z

More standardization

C++11: Switch from auto_ptr to unique_ptr

2015-08-13T09:30:59Z

This is nicer

move manual-bit from 'oldlibs' pkg to its dependencies

2015-08-10T15:27:59Z

oldlibs used to be in APT::Never-MarkAuto-Sections so that old transition packages can be removed without causing the then (autoinstalled) renamed package to be autoremoved. It isn't ideal through as ideally you want the oldlibs package to be removed after nothing depends on it anymore regardless of if you have once installed it by hand or not – and if you had the package talking over (the dependencies) should carry the manual bit now as they are the real deal now. As an added bonus if the package has no dependencies because it is an oldlibs without a direct replacement you should move away from (like lib1 and lib2 are currently in the archive, but there will hopefully only be lib2 in the release) you get a lib1 marked as auto. If the user still needs the oldlibs package for some reason all he has to do is mark it as manual once as this move is only performed if a installed package changes its section from a not-Move-Autobit-Sections to a Move-Autobit-Sections.

move APT::Never-MarkAuto-Sections handling to MarkDelete

2015-08-10T15:27:59Z

Having the handling in MarkInstall means that it just effects installation of the metapackage, but if the dependencies change the new dependencies aren't protected (and the old dependencies are still protected for no 'reason'). Having it in MarkDelete means that if a metapackage is sheduled for removal all its currently installed dependencies are marked as manual, which helps against both as in this case there is no new/old and additionally if a user decides the installation of a metapackage was wrong he can just remove it explicitely avoid the manual marking entirely.

mark again deps of pkgs in APT::Never-MarkAuto-Sections as manual

2015-08-10T15:27:59Z

In 50ef3344c3afaaf9943142906b2f976a0337d264 (and similar for other branches), while 'fixing' the edgecase of a package being in multiple sections (e.g. moved from libs to oldlibs in newer releases) I accidently broke the feature itself completely by operating on the package itself and no longer on its dependencies… The behaviour isn't ideal in multiple ways, which we are hopefully able to fix with new ideas as mentioned in the buglog, but until then the functionality of this "hack" should be restored. Reported-By: Raphaël Hertzog Tested-By: Adam Conrad Closes: 793360 LP: 1479207 Thanks: Raphaël Hertzog and Adam Conrad for detailed reports and initial patches

split-up Dependency struct

2015-08-10T15:27:18Z

Having dependency data separated from the link between version/package and the dependency allows use to work on sharing the depdency data a bit as it turns out that many dependencies are in fact duplicates. How many are duplicates various heavily with the sources configured, but for a single Debian release the ballpark is 2 duplicates for each dependency already (e.g. libc6 counts 18410 dependencies, but only 45 unique). Add more releases and the duplicates count only rises to get ~6 for 3 releases. For each architecture a user has configured which given the shear number of dependencies amounts to MBs of duplication. We can cut down on this number, but pay a heavy price for it: In my many releases(3) + architectures(3) test we have a 10% (~ 0.5 sec) increase in cache creationtime, but also 10% less cachesize (~ 10 MB). Further work is needed to rip the whole benefits from this through, so this is just the start. Git-Dch: Ignore