Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.1.5 2020-05-25T10:05:00Z 2020-05-25T10:05:00Z David Kalnischkies david@kalnischkies.de 2020-05-14T09:24:28Z urn:sha1:10f87f7e3f08335421fd60a2b49840289cd737de The non-virtual base-destructor causes its derivate classes to leak tiny bits of memory otherwise. The header is private and not to be used outside of APT, so we can perform this tiny ABI break as there is no ABI to break. Reported-By: valgrind and clang -fsanitize=leak 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. 2020-05-25T10:05:00Z David Kalnischkies david@kalnischkies.de 2020-05-24T14:36:03Z urn:sha1:c3bfdbfa3ae868515a67142d2df6200a3cb34d35 ../apt-pkg/init.cc:137:39: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] Cnf.CndSet("Dir::State", STATE_DIR + 1); ../apt-pkg/init.cc:137:39: note: use array indexing to silence this warning We have a few instances of that & it should be reasonably clear that we are not actually trying to append here, but ignoring or silencing this warning with an override is far more costly than just using what clang suggests here. Reported-By: clang Gbp-Dch: Ignore 2020-05-25T10:05:00Z David Kalnischkies david@kalnischkies.de 2020-05-24T14:27:15Z urn:sha1:90a7a5e32643a67f4245460e7659d9dee230e9e7 ../apt-pkg/edsp.cc:861:23: error: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] const char *arch = _config->Find("APT::Architecture").c_str(); Compilers are probably optimizing it the way the patch does by hand now. Small string optimisation helps likely as well. Othwise that should have failed left and right as EDSP is used by experimental and such builders to talk to aspcud. Reported-By: clang 2020-05-25T10:05:00Z David Kalnischkies david@kalnischkies.de 2020-05-23T15:15:32Z urn:sha1:c77566fd8f21a1a44efb4092c90996d1cc8eaf24 2020-05-25T10:05:00Z David Kalnischkies david@kalnischkies.de 2020-05-23T14:55:59Z urn:sha1:0e5a9bf95d5b9b3c775ed3ce6142d35815a7c7ac Gbp-Dch: Ignore 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. 2020-05-23T15:59:19Z David Kalnischkies david@kalnischkies.de 2020-05-23T13:53:06Z urn:sha1:4f71dc657c34915508a9e34b000e1b577931655a It looks like hack and therefore I wanted this to be a very isolated commit so we can find it & revert it easily if need be, but for now it seems to work. The idea is that Status is telling us how the candidate is in relation to the current installed version which is used to figure out if a package is "kept back" by the algorithm or not, but by discarding the candidate version we loose this information. Ideally we would keep better tabs on what we do to a package and why, but for now that seems okayish. It will cause the wrong version to be displayed though as if the package is installed the installed version becomes the candidate and hence (installed => installed) is displayed. 2020-05-23T15:58:42Z David Kalnischkies david@kalnischkies.de 2020-05-22T17:52:26Z urn:sha1:4d87856b94dae1a40a1a8147a6dbcfe714cd05c7 If we have a negative dependency to deal with we prefer to install an upgrade rather than remove the current version. That is why we split the method rather explicitly in two in 57df273 but there is a case we didn't react to: If we have seen the candidate before as a "satisfier" of this negative dependency there is no point in trying to upgrade to it later on. We keep that info by candidate discard if we can, but even if we can't we can at least keep that info around locally. This "fixes" (or would hide) the problem described in 04a020d as well as you don't have to discard installations you never make. 2020-05-23T15:58:42Z David Kalnischkies david@kalnischkies.de 2020-05-22T16:56:40Z urn:sha1:04a020d7a217d6b5af86c048c2974760053b8079 For a (partially) installed package like the one MarkInstall operates on at the moment we want to discard the candidate from, we have to first remove the package from the internal state keeping to have proper broken counts and such and only then reset the candidate version which is a trivial operation in comparison. Take a look at the testcase: Now, what is the problem? Correct, git:i386. Didn't see that coming, right? It is M-A:foreign so apt tries to switch the architecture of git here (which is pointless, it knows that this won't work, but lets fix that in another commit) will eventually realize that it can't install it and wants to discard the candidate of git:i386 first removing the broken indication like it should, removing the install flag and then reapplies the broken indication: Expect it doesn't as it wants to do that over the candidate version which the package no longer had so seemingly nothing is broken. It is a bit of a hairball to figure out which commit it is exactly that is wrong here as they are all influencing each other a bit, but >= 2.1 is an acceptable ballpark. Bisect says 57df273 but that is mostly a lie. Closes: #961266