Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.7.12 2024-02-20T12:49:04Z 2024-02-20T12:49:04Z Julian Andres Klode julian.klode@canonical.com 2024-02-20T12:43:08Z urn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49 This was automated with sed and git-clang-format, and then I had to fix up the top of policy.cc by hand as git-clang-format accidentally indented it by two spaces. 2024-02-13T13:27:27Z Julian Andres Klode julian.klode@canonical.com 2024-02-12T13:48:48Z urn:sha1:a8352c2859a6f84b36fa5cd0af89231cb656b1ce This moves the functions of the PhasedUpgrader class into various other classes so they can be publicly exposed. This introduces three new functions: pkgDepCache::PhasingApplied() tells you whether phasing should be applied to the package. pkgProblemResolver::KeepPhasedUpdates() keeps back updates that have phasing applied. pkgCache::VerIterator::IsSecurityUpdate() determines whether this version contains security fixes. 2023-12-04T23:35:04Z David Kalnischkies david@kalnischkies.de 2023-12-04T19:49:33Z urn:sha1:0abf584b283e3e0f040b9ec0e7153c6e52291b2a Usually this method will return the package in the most preferred architecture (e.g. native) as that is usually what the user talks about and also information wise for our internal usage the most dense. Early on in parsing Packages files through it can happen that we encounter stanzas about packages in architectures we are not even configured to know about – we have to collect them anyhow as we might be requested to show info about them or they could be in the status file and we can't ignore stanzas in the status file… trouble is that this method used to not return anything if only such an architecture was present if we later discover other architectures which causes Provides and Conflicts which are added lazily on discovery of an architecture to not be added correctly. The result is like in the testcase that apt could be instructed to install a package without respecting its negative dependencies, which is bad even if its discovered by dpkg and refused. It does only happen with unknown architectures through which mostly happens if you are unlucky (amd64 users tend to be very lucky as that sorts early) and use flat-style repositories containing multiple architectures. Reported-By: Tianyu Chen (billchenchina) on IRC 2021-10-19T16:25:51Z Julian Andres Klode julian.klode@canonical.com 2021-10-19T16:11:14Z urn:sha1:307912e8d74d9684875a791b0550c10afc14b0b0 Fix a regression in python-apt where switching the architectures in the config between cache invocations regressed. Regression-Of: 8ff4e226af55a9feb168477a2b1a99f9c5152e54 Gbp-Dch: full 2021-09-04T13:35:15Z David Kalnischkies david@kalnischkies.de 2021-09-04T11:03:05Z urn:sha1:8ff4e226af55a9feb168477a2b1a99f9c5152e54 Back in 2015 the code inside libapt who was using this field was dropped as even if we are on a system which is not configured for MultiArch, there are still edge cases in which the cache can include very foreign packages, so any assumption you could make thinking only a single architecture will be in the cache is probably wrong. Maintaining two different codepaths for Multi- and SingleArch is likely not very beneficial for code and users alike and is surprisingly hard to answer correctly and becoming even harder still, so always assuming the "worst case" seems like the far better option. References: 6c9937da76b9155d166092b9dda22d06200510c1 2021-02-03T16:36:45Z David Kalnischkies david@kalnischkies.de 2021-02-03T09:55:09Z urn:sha1:cd1f75854824b3db7ba86039463528f834a0838a We do this once (usually), so the leak is tremendously big, but it is detected as a leak by the fuzzer and trips it up. 2020-12-15T21:13:12Z Julian Andres Klode julian.klode@canonical.com 2020-12-15T19:57:32Z urn:sha1:c6d40932f81edc656bbcc8dbd9d277aba543bc5b Unroll pkgCache::sHash 8 times and break up the dependency between the iterations by expanding the calculation H(n) = 33 * H(n-1) + c 8 times rather than performing it 8 times. This seems to yield about a 0.4% performance improvement. I tried unrolling 4 and 2 bytes as well, those only having 3 ifs at the end rather than 1 small loop; but that was actually slower - potentially the code got to large and the cache went bonkers. I also tried unrolling 4 times instead of 8, thinking that smaller code might yield better results overall then, but that was slower as well. 2020-12-15T12:47:22Z Julian Andres Klode julian.klode@canonical.com 2020-12-13T20:07:03Z urn:sha1:1460eebf2abe913df964e031eff081a57f043697 XXH3 is faster than both our CRC32c implementation as well as DJB hash for hash table hashing, so meh, let's switch to it. 2020-12-10T14:40:08Z Julian Andres Klode julian.klode@canonical.com 2020-12-08T10:52:26Z urn:sha1:07808e0d08e8e95e06b754f4c37665015b1045a7 We now have over 100k package names, my Ubuntu system has 125k arleady, so increase the hash table size to match, this will cost us about a MB in cache size, but give a very nice speed up somewhere around 3%-4% or so. 2020-05-25T10:05:00Z David Kalnischkies david@kalnischkies.de 2020-05-21T20:17:42Z urn:sha1:574249cd721a3cdbb79b6e457384a55827856b6a As the builtins were used in the feature test also in the default branch clang fails to compile the test helpfully complaining that you need to compile with sse4.2 to use that while on gcc it is optimized out as unused code and produces only a warning for that… removing the code from the default branch fixes this problem, but we adapt the code some more to avoid compilers optimizing it out in the future just in case.