Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.29 2025-02-03T12:40:37Z 2025-02-03T12:40:37Z Julian Andres Klode julian.klode@canonical.com 2025-02-03T12:19:12Z urn:sha1:452586e84ad54ca23dee399bf9809c49e7171f36 I don't know why I used a double here this is awkward. 2025-01-05T22:16:08Z David Kalnischkies david@kalnischkies.de 2024-12-26T19:41:53Z urn:sha1:f73593a4034d9eec0ec4466b8e173d4a4daece1f We were rather inconsistent in using it and as our public headers contain deduction guides (a c++17 feature) it seems silly to try to hide a c++11 feature in a macro, so lets stop this charade and drop the macro and while we are changing all these lines lets apply [[nodiscard]] (another c++17 feature) and other suggestions from clang-tidy and formatting for a little more consistency. 2024-04-13T18:27:48Z Julian Andres Klode jak@debian.org 2024-04-13T18:27:48Z urn:sha1:f7e5ed3c8dffcdfc2c55c63f2e3cbcb390bbf013 Calculate an estimate of 110% of the biggest initrd + system.map as the additional space a kernel needs in /boot. If /boot is a different file system than /usr, print the size of the kernels + the additional space they will need separately; otherwise include it in our /usr figure. 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. 2021-08-28T20:21:35Z David Kalnischkies david@kalnischkies.de 2021-08-28T17:22:26Z urn:sha1:d7e9f0779043814d6e7a4141170fa7f18cd90803 We can't have external users as its marked hidden and as we don't even have users outside of pkgDepCache itself we can remove the function completely from the public eye. That adds many new parameters, but it also allows to add a few more like avoiding constantly checking the debug config value. Gbp-Dch: Ignore 2021-04-26T11:00:24Z David Kalnischkies david@kalnischkies.de 2021-03-18T16:37:49Z urn:sha1:d6f3458badf2cfea3ca7de7632ae31daff5742be An interactive tool like aptitude needs these flags current far more often than we do as a user can see them in apt only in one very well defined place – the autoremove display block – so we don't need to run it up to four times while a normal "apt install" is processed as that is just busywork. The effect on runtime is minimal, as a single run doesn't take too long anyhow, but it cuts down tremendously on debug output at the expense of requiring some manual handholding. This is opt-in so that aptitude doesn't need to change nor do we need to change our own tools like "apt list" where it is working correctly as intended. A special flag and co is needed as we want to prevent the ActionGroup inside pkgDepCache::Init to be inhibited already so we need to insert ourselves while the DepCache is still in the process of being built. This is also the reason why the debug output in some tests changed to all unmarked, but that is fine as the marking could have been already obsoleted by the actions taken, just inhibited by a proper action group. 2021-01-04T09:43:31Z Julian Andres Klode julian.klode@canonical.com 2020-12-17T12:20:53Z urn:sha1:290a4cf9455f45895718ed698147061fcd0a2dcb This avoids the cost of setting up the function every time we mark and sweep. 2020-07-02T16:57:11Z David Kalnischkies david@kalnischkies.de 2020-06-19T11:14:33Z urn:sha1:3e39efa31da463ca05016513835d9a5388f80f90 Marking a package for removal is fine if we know that we have to remove that package, but if we are in an alternative branch we might not go this route in the end and hence have a package pointlessly marked for removal which isn't questioned later on. We check if we are allowed to remove that package to avoid working on the positive dependencies if not, but we mark them for removal only after all the other dependencies are successfully resolved. In an ideal world we would let the problemResolver do its job on them, but the resolver might decide against doing the removal exploring another option like the next alternative, which might be a good idea, but is not the behaviour we had before, so that is the best we can do for now without changing the resolver drastically. 2020-05-24T19:02:35Z David Kalnischkies david@kalnischkies.de 2020-05-23T14:22:44Z urn:sha1:2ba86f95bfad4ec00a3b99b311d05c158162b25c For speed reasons pkgDepCache initializes its state once and then has a battery of update calls you have to invoke in the right order to update the various states – all in the name of speed. In debug and/or simulation mode we can sacrifice this speed for a bit of extra checking though to verify that we haven't made some critical mistake like #961266.