Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.9.27 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-02-03T12:40:37Z Julian Andres Klode julian.klode@canonical.com 2025-02-03T12:07:37Z urn:sha1:c303750ecb89b7210fe998515432e358b3cc0cff Change the code to get the size from the existing vmlinuz, rather than using the package size, which only worked in Ubuntu, and possibly not on all kernel packages either. Refactor the code a bit to avoid the nested if as well, and use off_t to measure and sum the sizes before switching to floating point. Closes: #1085184 2025-01-30T23:39:50Z David Kalnischkies david@kalnischkies.de 2025-01-30T23:39:50Z urn:sha1:ce3794a7df13f3d7387b4e4520221421ee92127b It is a tiny struct, so the difference in 'stats' is minor even with all the versions but it is more correct and also helps in case the Extra struct is changed to predictably trigger a binary cache invalidation. 2025-01-30T23:10:02Z David Kalnischkies david@kalnischkies.de 2025-01-30T23:10:02Z urn:sha1:593cf30cee476bdae21f7e99f67d2572b7381e90 Avoiding duplications is one thing, but it could also be handy to know all sources for a description so that you can e.g. avoid opening another file or similar such if its also present in one you already have open. Given how the structures were set up this was probably intended all along and either worked at some point or was abandoned for the duplicates that we started culling heavily with the introduction of MultiArch as at that point they blew up the cache and needed to be dealt with. 2025-01-30T21:45:40Z David Kalnischkies david@kalnischkies.de 2025-01-30T21:45:40Z urn:sha1:d0c2cc03d75fa66986a9aadf8b1361426e9ceb4d The architectures are supposed to share the descriptions as they are (very usually) the same, but the code was happily creating structs for every architecture of a package which is especially pointless as for e.g. Debian those will be the short description likely superseded in output and all uses by the 'en' "translation". 2025-01-30T19:10:50Z David Kalnischkies david@kalnischkies.de 2025-01-30T18:03:26Z urn:sha1:1bc8dab8df60c5da7cc817bec5f53e60f7eb9817 Same reason as with the description size before, but this one had actually one extremely dated user in src:apt left with dumpavail, which is changed to an implementation that is (in comparison) a bit slower, but should be good enough for a command that is ideally not used anymore (even if codesearch suggests otherwise). After all, what makes this a bit slower is not that we don't know the size, but that this one does additional work preparing for accessing the fields which we don't do. In exchange pkgTagFile has a better implementation for "Jitter" than the old code that we would "just" need to copy here if speed were really an issue. 2025-01-30T16:39:40Z David Kalnischkies david@kalnischkies.de 2025-01-30T16:39:40Z urn:sha1:1bc221a9dd22baa6e2e516d45dc858774cafddd0 Nothing in src:apt uses this information and that isn't all to surprising as it is usually not that interesting to know how big a specific stanza of a description is as the max size is available and you are usually working with more than one description. So this information just takes up space in our binary cache… 64 bits per structure which can quickly add up to whole MBs depending on how many (and which) sources you have enabled. 2025-01-30T15:22:14Z David Kalnischkies david@kalnischkies.de 2025-01-30T15:22:14Z urn:sha1:2e39d0fdeff5f9db91b3490d6750c8033aca9057 The counters aren't used for anything really except for the 'stats' command that is off in its display and calculation due to 16bit not being enough for counting all the relations we have. Semi-broken more than a decade ago as I accidentally aligned it with the other file relation counters which count far less frequent ones through, so 'unsigned long' should have been changed to the id type rather than the smaller fileid type. Of course, this commit only prepares the fix as this would be an ABI break, so with the current ABI we are still overflowing. Regression-of: 4ad8619bb1f0bf777d17c568bb7a6cf7f30aac34 2025-01-30T14:36:10Z Julian Andres Klode julian.klode@canonical.com 2025-01-30T14:34:51Z urn:sha1:945ead2ab03b7c83b3fbaecf3e1e543525e476f0 Gbp-Dch: ignore 2025-01-30T13:50:15Z Julian Andres Klode julian.klode@canonical.com 2024-11-02T12:55:39Z urn:sha1:3523efb15d48ce3c6f9212f50dfc892497ba9dcb Instead of directly propagating in a recursive fashion, queue propagations in a queue and work on them in a loop per the miniSAT paper. We call Propagate() only at the end of the FromDepCache() function and then in the Solve loop. Delaying the initial propagation means that we get a stronger reasoning: Assume you have x->a->b->c, y->c and you install x,y: - Previously we traversed: x, y, x->a, a->b, b->c, (y->c) - but now we traverse: x, y, x->a, y->c, a->b, (b->c) Notably c now has the implication y->c instead of x->a->b->c. Inside the solver we need to call Propagate in a loop: Propagating facts can fail and we then backtrack. If backtracking is succesful, we have gained a new fact to propagate.