Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1.exp1 2014-06-18T10:41:11Z 2014-06-18T10:41:11Z David Kalnischkies david@kalnischkies.de 2014-06-13T06:35:32Z urn:sha1:7a66977486804d46d5860f568cbd80f54f0c42d0 A version belongs to a section and has hence a section member of its own. A package on the other hand can have multiple versions from different sections. This was "solved" by using the section which was parsed first as order of sources.list defines, but that is obviously a horribly unpredictable thing. We therefore directly remove this struct member to free some space and mark the access method as deprecated, which is told to return the section of the 'newest' known version, which is at least predictable, but possible not what it returned before – but nobody knows. Users are way better of with the Section() as returned by the version they are dealing with. It is likely the same for all versions of a package, but in the few cases it isn't, it is important (like packages moving from main/* to contrib/* or into oldlibs …). 2014-06-18T10:41:11Z David Kalnischkies david@kalnischkies.de 2014-06-12T10:22:45Z urn:sha1:4ad8619bb1f0bf777d17c568bb7a6cf7f30aac34 We had a wild mixture of (unsigned) int, long and long long here without much sense, so this commit adds a few typedefs to get some sense in the typesystem and ensures that a ID isn't sometimes computed as int, stored as long and compared with a long long… as this could potentially bite us later on as the size of the archive only increases over time. 2014-06-18T10:41:11Z David Kalnischkies david@kalnischkies.de 2014-06-11T18:42:16Z urn:sha1:e8a7b0b28ca01cd8c2c1bee0d83e5997b40de689 It also makes the size configureable, so it can be adapted in the future without the need for an abi break - and even by users… The increase was long overdue as it gives a >10% decrease in runtime of e.g. 'apt-get check -s'. Some (useless) benchmark with 69933 groups and 187796 packages without a pre-built cache: time apt-get check -so APT::Cache-HashTableSize=1 → 20m time apt-get check -so APT::Cache-HashTableSize=1000 → 6,41s time apt-get check -so APT::Cache-HashTableSize=2000 → 5,64s (old) time apt-get check -so APT::Cache-HashTableSize=3000 → 5,30s time apt-get check -so APT::Cache-HashTableSize=5000 → 5,08s time apt-get check -so APT::Cache-HashTableSize=6000 → 5,05s time apt-get check -so APT::Cache-HashTableSize=7000 → 5,02s time apt-get check -so APT::Cache-HashTableSize=8000 → 5,00s time apt-get check -so APT::Cache-HashTableSize=9000 → 4,98s time apt-get check -so APT::Cache-HashTableSize=10000 → 4,96s (new) time apt-get check -so APT::Cache-HashTableSize=15000 → 4,90s time apt-get check -so APT::Cache-HashTableSize=20000 → 4,86s time apt-get check -so APT::Cache-HashTableSize=30000 → 4,77s time apt-get check -so APT::Cache-HashTableSize=40000 → 4,74s time apt-get check -so APT::Cache-HashTableSize=50000 → 4,73s time apt-get check -so APT::Cache-HashTableSize=60000 → 4,71s The gap increases further for operations which have more package lookups. Factor 5 was chosen as higher values do not provide any really significant timing advantage anymore compared to the memory increase in my testing and there is always the possibility to increase it now if that changes. (also most users will not have 3 releases and 4 architectures in the cache, so theirs will be much smaller and faster). 2014-06-18T08:13:01Z Michael Vogt mvo@debian.org 2014-06-18T08:13:01Z urn:sha1:da029b0aaebdc64a3a9f6b7012213539421c934b Conflicts: apt-pkg/acquire-item.cc apt-pkg/acquire-item.h apt-pkg/deb/debmetaindex.h apt-pkg/pkgcache.cc test/integration/test-apt-ftparchive-src-cachedb 2014-06-18T07:35:53Z Michael Vogt mvo@ubuntu.com 2014-06-18T07:35:53Z urn:sha1:b686f453b14e11a69ecbd368509f7eaf1596c6e0 This is a internal struct not a external interface so the actual breakage should be small. 2014-05-29T08:29:21Z Michael Vogt mvo@debian.org 2014-05-29T08:29:21Z urn:sha1:43f8819b7fbfd24c5013bbe3183cd85e10e77af3 2014-05-10T10:50:00Z David Kalnischkies david@kalnischkies.de 2014-05-10T10:50:00Z urn:sha1:7a223b933cab0447438ca2e964576da39078eaf4 The cache heavily depends on the architecture(s) it is build for, especially if you move from single- to multiarch. Adding a new architecture to dpkg therefore has to be detected and must invalidate the cache so that we don't operate on incorrect data. The incorrect data will prevent us from doing otherwise sensible actions (it doesn't allow bad things to happen) and the recovery is simple and automatic in most cases, so this hides pretty well and is also not as serious as it might sound at first. Closes: 745036 2014-05-07T15:55:10Z Michael Vogt mvo@debian.org 2014-05-07T15:55:10Z urn:sha1:38d2959ffb8c6f5f291b2910014a67b1b352ab4c Conflicts: apt-pkg/cachefilter.h apt-pkg/contrib/fileutl.cc apt-pkg/contrib/netrc.h apt-pkg/deb/debsrcrecords.cc apt-pkg/init.h apt-pkg/pkgcache.cc debian/apt.install.in debian/changelog 2014-03-13T12:58:45Z David Kalnischkies david@kalnischkies.de 2014-03-05T23:33:10Z urn:sha1:a02db58fd50ef7fc2f0284852c6b3f98e458a232 Git-Dch: Ignore Reported-By: gcc -Wsuggest-attribute={pure,const,noreturn} 2014-03-13T12:58:45Z David Kalnischkies david@kalnischkies.de 2014-03-01T12:55:20Z urn:sha1:d64e130aa333837a8fda0f1bba51f2867ca520f7 Reported-By: gcc -Wignored-qualifiers Git-Dch: Ignore